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10 GroupWise 6.5 Interoperability Guide 


About This Guide 


This Novell® Group Wise® 6.5 Interoperability Guide helps you use GroupWise in the context of 
other software products. The guide provides assistance with Novell products and third-party 


products: 
Novell Products + “Novell Cluster Services” on page 13 
+ “GroupWise DirXML Driver for Novell Identity Manager” on 
page 121 
+ “GroupWise Customization Tools” on page 127 
Third-Party Products + “Microsoft Clustering Services” on page 129 


+ “Non-GroupWise Clients” on page 197 


For information about additional Group Wise-related software from Group Wise partners, see the 
Group Wise Partners Web site (http://www.novell.com/products/groupwise/partners). 


Additional Documentation 


For additional GroupWise documentation, see the following guides at the Novell GroupWise 6.5 
documentation Web site (http://www.novell.com/documentation/gw65): 


¢ Installation Guide 

+ Administration Guide 

+ Multi-System Administration Guide 
¢ Troubleshooting Guides 

+ GroupWise Client User Guides 


Documentation Updates 


For the most recent version of the GroupWise 6.5 Interoperability Guide, visit the Novell 
Group Wise 6.5 documentation Web site (http://www.novell.com/documentation/gw65). 


Documentation Conventions 


In Novell documentation, a greater-than symbol (>) is used to separate actions within a step and 
items within a cross-reference path. 


A trademark symbol (™, e etc.) denotes a Novell trademark. An asterisk denotes a third-party 
trademark. 
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User Comments 


We want to hear your comments and suggestions about this manual and the other documentation 
included with this product. Please use the User Comment feature at the bottom of each page of the 
online documentation, or go to www.novell.com/documentation/feedback.html and enter your 
comments there. 
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Novell Cluster Services 


Chapter 1, “Introduction to GroupWise 6.5 and Novell Cluster Services,” on page 15 

Chapter 2, “Planning GroupWise in a Novell Cluster,” on page 17 

Chapter 3, “Setting Up a Domain and Post Office in a Novell Cluster,” on page 37 

Chapter 4, “Implementing the Internet Agent in a Novell Cluster,” on page 63 

Chapter 5, “Implementing WebAccess in a Novell Cluster,” on page 83 

Chapter 6, “Implementing GroupWise Gateways in a Novell Cluster,” on page 103 

Chapter 7, “Monitoring a GroupWise System in a Novell Cluster,” on page 105 

Chapter 8, “Backing Up a GroupWise System in a Novell Cluster with the GroupWise TSA,” on 
page 107 

Chapter 9, “Moving an Existing GroupWise 6.5 System into a Novell Cluster,” on page 109 

Chapter 10, “Implementing Messenger in a Novell Cluster,” on page 111 
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Introduction to GroupWise 6.5 and Novell 
Cluster Services 


Before implementing GroupWise® 6.5 with Novell® Cluster Services™, make sure you have a 
solid understanding of Novell Cluster Services by reviewing the following information resources: 


+ AppNote: An Introduction to Novell Cluster Services (http://support.novell.com/techcenter/ 
articles/anal9990501.html) 


+ NetWare 6 Product Documentation: Novell Cluster Services (http://www.novell.com/ 
documentation/lg/ncs6p/index.html) 


+ NetWare 5.1 Product Documentation: Novell Cluster Services (http://www.novell.com/ 
documentation/lg/ncs/index.html) 


When you review the information resources recommended above, you discover that clustering 
employs very specialized terminology. The following brief glossary provides basic definitions of 
clustering terms and relates them to your GroupWise system: 


cluster: A grouping of from two to 32 NetWare® servers configured using Novell Cluster Services 
so that data storage locations and applications can transfer from one server to another without 
interrupting their availability to users. 


node: A clustered server; in other words, a single NetWare server that is part of a cluster. 


resource: An IP address, volume, application, service, and so on, that can function successfully 
anywhere in the cluster. The volumes where domains and post offices reside are a specific type of 
cluster resources termed "volume resources." In this section, the terms "cluster resource" and 
"volume resource" are used instead of "resource" to avoid confusion with GroupWise resources 
(such as conference rooms and projectors). 


failover: The process of moving cluster resources from a failed node to a functional node so that 
availability to users is uninterrupted. For example, if the node where the POA is running goes 
down, the POA and its post office would fail over to a secondary node so that users could continue 
to use GroupWise. When setting up cluster resources, you need to consider what components need 
to fail over together in order to continue functioning. 


fan-out-failover: The configuration where cluster resources from a failed node fail over to 
different nodes in order to distribute the load from the failed node across multiple nodes. For 
example, if a node runs a cluster resource consisting of a domain and its MTA, another cluster 
resource consisting of a post office and its POA, and a third cluster resource for WebAccess, each 
cluster resource could be configured to fail over separately to different secondary nodes. 


failback: The process of returning cluster resources to their preferred node after the situation 
causing the failover has been resolved. For example, if a POA and its post office fail over to a 
secondary node, that cluster resource can be configured to fail back to its preferred node when the 
problem is resolved. 
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migration: The process of manually moving a cluster resource from its preferred node to a 
secondary node for the purpose of performing maintenance on the preferred node, temporarily 
lightening the load on the preferred node, and so on. 


shared disk system: The hardware housing the physical disk volumes that are shared among the 
cluster nodes. 


shared volume: A volume in a shared disk system that can be accessed from any cluster node that 
needs the data stored on it. 


cluster-enabled shared volume: A shared volume for which a Volume Resource object has been 
created in Novell eDirectory™. The properties of the Volume Resource object provide load and 
unload scripts for programs installed on the volume, failover/failback/migration policies for the 
volume, and the failover path for the volume. Cluster-enabling is highly recommended for 

Group Wise. 


GroupWise volume: As used in this section, a cluster-enabled shared volume that is used for 
GroupWise, such as for storing a domain, post office, software distribution directory, and so on. 
This section also uses the terms Internet Agent volume, WebAccess Agent volume, Messenger 
volume, and gateway volume in a similar manner. 


storage area network (SAN): The cluster nodes together with their shared disk system and shared 
volumes. 


virtual server: A logical server, rather than a physical server, to which cluster-enabled shared 
volumes are tied. 


active/active mode: The configuration of a clustered application where the application runs 
simultaneously on multiple nodes in the cluster. Active/active mode is recommended when the 
GroupWise MTA, POA, Internet Agent, and WebAccess Agent run in protected memory because 
protected memory isolates them from each other, even if they are running on the same node. 
Active/active mode is also recommended when configuring the Netscape* Enterprise Server* for 
use with GroupWise WebAccess. 


active/passive mode: The configuration of a clustered application where the application runs on 
only one node at a time in the cluster. The GroupWise MTA, POA, Internet Agent, and WebAccess 
Agent must run in active/passive mode if they are not running in protected memory because only 
one instance of each agent/database combination can be running at the same time in the cluster. 
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Planning GroupWise in a Novell Cluster 


The majority of this part of the GroupWise 6.5 Interoperability Guide (Chapter 2, “Planning 
Group Wise in a Novell Cluster,” on page 17 through Chapter 8, “Backing Up a Group Wise System 
ina Novell Cluster with the GroupWise TSA,” on page 107) is designed for those who are creating 
anew GroupWise® system, or at least new domains and post offices, in the context of Novell® 
Cluster Services™. If you already have an existing Group Wise 6.5 system and need to configure it 
to work in a newly installed cluster, see Chapter 9, “Moving an Existing GroupWise 6.5 System 
into a Novell Cluster,” on page 109. 


When you implement a new GroupWise system or a new domain or post office in a clustering 
environment, overall GroupWise system design does not need to change substantially. For a 
review, see “Installing a Basic GroupWise System” in the GroupWise 6.5 Installation Guide. 
However, the configuration of individual components of your GroupWise system will be 
significantly different. This section helps you plan the following GroupWise components in a 
cluster: 


+ A new GroupWise system consisting of the primary domain and the initial post office 
+ A new secondary domain 
+ Anew post office 


+ The GroupWise agents (MTA and POA) 


During the planning process, component configuration alternatives will be explained. For 
example, you might want the domain and post office together on the same shared volume or on 
different shared volumes. You might want to install the agents to standard sys:\system directories 
or to manually created vol:\system directories on shared volumes where domains and post offices 
reside. You might or might not need to run the agents in protected memory. 


The “System Clustering Worksheet” on page 32 lists all the information you will need as you set 
up GroupWise in a clustering environment. You should print the worksheet and fill it out as you 
complete the tasks listed below: 


+ “Meeting Software Version Requirements” on page 18 

+ “Installing Novell Cluster Services” on page 19 

+ “Planning a New Clustered Domain” on page 20 

+ “Planning a New Clustered Post Office” on page 21 

+ “Planning a New Library for a Clustered Post Office” on page 21 

+ “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21 
+ “Ensuring Successful Name Resolution for GroupWise Volumes” on page 23 

¢ “Deciding How to Install and Configure the Agents in a Cluster” on page 25 

+ “GroupWise Clustering Worksheets” on page 32 
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After you have completed the tasks and filled out the “System Clustering Worksheet” on page 32, 
you will be ready to continue with Chapter 3, “Setting Up a Domain and Post Office in a Novell 
Cluster,” on page 37. 


Meeting Software Version Requirements 


Group Wise 6.5 can be clustered on a system that meets the following requirements: 
+ GroupWise 6.5 
+ NetWare® 6 
or 
NetWare 5.1 with Support Pack 3 or higher 


IMPORTANT: Novell Cluster Services does not support mixed NetWare versions within a cluster. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 1: Software Version Updates for Cluster, mark any updates required for nodes in the 
cluster. 


As needed, update the servers that will become part of the cluster you are preparing for your 
GroupWise system. 


+ “Upgrading to NetWare 6.x” on page 18 
+ “Updating to NetWare 5.1 Support Pack 3 or Higher” on page 18 


Upgrading to NetWare 6.x 


If you are implementing clustering for the first time in your system, you might want to take the 
opportunity to upgrade to NetWare 6.x at the same time. You can purchase NetWare 6.x at NetWare 
6: How to Buy (http://www.novell.com/products/netware/howtobuy.html). 


Updating to NetWare 5.1 Support Pack 3 or Higher 


If you are still running NetWare 5.0 or earlier and do not want to upgrade to NetWare 6.x, you must 
update all nodes in the cluster to NetWare 5.1 in order to run GroupWise in the cluster. You can 
purchase NetWare 5.1 at shopNovell (http://shop.novell.com). 


After NetWare 5.1 is installed on all the nodes in the cluster, you must install NetWare 5.1 Support 
Pack 3 or higher. It includes changes that benefit the combination of NetWare 5.1 and Group Wise 
6.5. You can download NetWare 5.1 Support Pack 4 from TID 2961624: NetWare 5.1 Support 
Pack 4 (http://support.novell.com/servlet/tidfinder/296 1624). 


Updating to the Latest ConsoleOne Snap-In 


If you are using NetWare 5.1 with Support Pack 3, it is highly recommended that you download 
the latest ConsoleOne® snap-in for Novell Cluster Services. It includes changes that enable you to 
modify cluster-related object names. You can download the latest snap-in, along with the version 
of ConsoleOne that supports it, from Novell Software Downloads (http://download.novell.com/ 

sdMain.jsp). 
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Installing Novell Cluster Services 
Install Novell Cluster Services by following the instructions provided in NetWare Cluster Services 
Overview and Installation for your version of NetWare: 
+ NetWare 6.x: “Installation and Setup” 
+ NetWare 5.1: “Installation and Setup” 
The installation process includes: 
+ Meeting hardware and software requirements 
¢ Setting up a shared disk system 
+ Creating a new NetWare Cluster object to represent the cluster in Novell eDirectory™ 
+ Adding nodes to the cluster 
¢ Installing the Novell Cluster Services software on all nodes in the cluster 


+ Mounting the shared volumes where you will set up Group Wise domains and post offices and 
install the Group Wise agents 


As you install Novell Cluster Services, record key information about the cluster on the System 
Clustering Worksheet: 


SYSTEM CLUSTERING WORKSHEET 


Under Item 2: eDirectory Tree for Cluster, record the name of the eDirectory tree where the new 
NetWare Cluster object has been created. 


Under Item 3: Cluster Name, record the name of the NetWare Cluster object that you created for your 
GroupWise system. 


Under Item 4: Cluster Context, record the full context of the NetWare Cluster object. 


Under Item 5: Nodes in Cluster, list the nodes that you have added to the cluster. 


The number of nodes and shared volumes that are available in the cluster will strongly influence 
where you place GroupWise domains and post offices. You have several alternatives: 


+ Your whole GroupWise system can run in a single cluster. 


+ Parts of your GroupWise system can run in one cluster while other parts of it run in one or 
more other clusters. 


+ Parts of your GroupWise system can run in a cluster while other parts run outside of the 
cluster, on non-clustered servers. 


If you do not have the system resources to run all of your GroupWise system in a clustering 
environment, you must decide which parts have the most urgent need for the high availability 
provided by clustering. Here are some suggestions: 


+ Post offices and their POAs must be available in order for users to access their GroupWise 
mailboxes. Therefore, post offices and their POAs are excellent candidates for the high 
availability provided by clustering. 


+ Inalike manner, WebAccess provides user access to GroupWise mailboxes across the Internet 
through users’ Web browsers. It is another good candidate for clustering. 
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+ Domains and their MTAs are less noticeable to users when they are unavailable (unless users 
in different post offices happen to be actively engaged in an e-mail discussion when the MTA 
goes down). On the other hand, domains and their MTAs are critical to GroupWise 
administrators, although administrators might be more tolerant of a down server than end 
users are. Critical domains in your system would be the primary domain and, if you have one, 
a hub or routing domain. These domains should be in the cluster, even if other domains are 
not. 


+ The Internet Agent might or might not require high availability in your GroupWise system, 
depending on the importance of immediate messaging across the Internet and the use of POP3 
or IMAP4 clients by GroupWise users. 


There is no right or wrong way to implement GroupWise in a clustering environment. It all 
depends on the specific needs of your particular GroupWise system and its users. 


Planning a New Clustered Domain 


The considerations involved in planning a new domain in a clustering environment are essentially 
the same as for any other environment. 


¢ Primary Domain: If you are setting up a new Group Wise system in a clustering environment, 
you will be creating the primary domain as you complete the tasks in this section. In 
preparation, review “Planning Your Basic GroupWise System”, then print and fill out the 
“Basic GroupWise System Worksheet” in “Installing a Basic GroupWise System” in the 
GroupWise 6.5 Installation Guide. This covers planning the primary domain and an initial 
post office in the primary domain. 


¢ Secondary Domain: If your GroupWise system already exists, you will be creating a new 
secondary domain. In preparation, review “Planning a New Domain”, then print and fill out 
the “Domain Worksheet” in “Domains” in the GroupWise 6.5 Administration Guide. 


Regardless of the type of domain you are creating, keep in mind the following cluster-specific 
details as you fill out the worksheet you need: 


+ When you specify the location for the domain directory (and for a new GroupWise system, 
the post office directory) on the worksheet, include the shared volume where you want the 
directory to reside. 


+ Do not concern yourself with the GroupWise agent information on the worksheet. You will 
plan the agent installation later. If you are filling out the Basic Group Wise System Worksheet, 
stop with item 17. If you are filling out the Domain Worksheet, stop with item 10. 


When you have completed the worksheet, transfer the key information from the Basic Group Wise 
System Worksheet or the Domain Worksheet to the System Clustering Worksheet. 
SYSTEM CLUSTERING WORKSHEET 


Under Item 10: Domain Name, transfer the domain name and database directory to the System 
Clustering Worksheet. 


Under Item 7: Shared Volume for Domain, transfer the domain location to the System Clustering 
Worksheet. You will fill out the rest of the information under item 7 later. 


IMPORTANT: Do not create the new domain until you are instructed to do so in Chapter 3, “Setting Up a 
Domain and Post Office in a Novell Cluster,” on page 37. 
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Planning a New Clustered Post Office 


The considerations involved in planning a new post office in a clustering environment are 
essentially the same as for any other environment. The initial post office in a new Group Wise 
system is planned on the Basic GroupWise System Worksheet. To plan additional new post offices, 
review “Planning a New Post Office ”, then print and fill out the “Post Office Worksheet” in “Post 
Offices” in the GroupWise 6.5 Administration Guide. When you specify the locations for the post 
office directories, include the shared volumes where you want the post office directories to reside. 


When you have completed the worksheet, transfer key information from the Basic GroupWise 
System Worksheet or the Post Office Worksheet to the System Clustering Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 11: Post Office Name, transfer the post office name and database location to the System 
Clustering Worksheet. 


If you will create the post office on a different shared volume from where the domain is located, under 
Item 8: Shared Volume for Post Office, transfer the post office location to the System Clustering 
Worksheet. You will fill out the rest of the information under item 8 later. 


IMPORTANT: Do not create the new post office until you are instructed to do so in Chapter 3, “Setting Up a 
Domain and Post Office in a Novell Cluster,” on page 37. 


Planning a New Library for a Clustered Post Office 


The considerations involved in planning a new library in a clustering environment are essentially 
the same as for any other environment. You can plan a library for a clustered post office by 
following the standard instructions provided in “Creating and Managing Libraries” in the 
GroupWise 6.5 Administration Guide and filling out the “Basic Library Worksheet” or the “Full- 
Service Library Worksheet”. Then provide the library information on the System Clustering 
Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 14: Library Location, mark where you want to create the library’s document storage area. 


If the document storage area will be located outside the post office directory structure, specify a user 
name and password that the POA can use to access the volume where the document storage area 
will reside. 


IMPORTANT: Do not create the new library until you are instructed to do so in Chapter 3, “Setting Up a 
Domain and Post Office in a Novell Cluster,” on page 37. 


Deciding Whether to Cluster-Enable the Shared Volumes Used by 


GroupWise 


Cluster-enabling the shared volumes where domains and post offices reside greatly simplifies 

Group Wise administration. If you are creating a new GroupWise system, you might also want to 
cluster-enable shared volumes for the GroupWise administration snap-ins to ConsoleOne and for 
the GroupWise software distribution directory so that these locations are always available within 
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the cluster. To review the concept of cluster-enabled shared volumes, see the applicable section of 
Novell Cluster Services Overview and Installation for your version of NetWare: 


+ 


+ 


NetWare 6.x: “Cluster Enable Pools and Volumes” 
NetWare 5.1: “Cluster-Enable Volumes ” 


The advantages of cluster-enabling GroupWise volumes include: 


+ 


Drive mappings always occur through the virtual server associated with the cluster-enabled 
volume, rather than through a physical server. This guarantees that you will always be able to 
map a drive to the domain or post office database no matter which node it is currently located 
on. 


The GroupWise snap-ins to ConsoleOne will always work no matter which node is running 
ConsoleOne. 


Cluster-enabling the domain volume and installing the GroupWise agents to this volume 
guarantees that the GroupWise snap-ins to ConsoleOne will always be able to find the 
configuration files that they need to access. 


When you rebuild a domain database or a post office database, you do not need to determine 
which node the database is currently located on. 


Help desk personnel do not need to be trained to determine where GroupWise is running 
before they connect to a domain to create a new GroupWise user. 


When you cluster-enable a volume, additional eDirectory objects will be created: 


eDirectory Object Name and Description 
Object 


clustername_volumename (default object name) 


A new Volume object will represent the cluster-enabled volume. It will be created by 
renaming the original Volume object that was tied to a physical server and associating it 
with a virtual server instead. 


For example, if your cluster name is GWCLUSTER and your original volume name is 
gwvol1, the new Volume object representing the cluster-enabled volume would be named 
gwcluster_gwvol1. 


clustername_volumename_SERVER (default object name) 
A new Server object will represent the virtual server to which the new cluster-enabled 
volume is tied. 


Continuing with the above example, the new Server object representing the virtual server 
would be named GWCLUSTER_GWVOL1_SERVER. 


ap volumename_SERVER.clustername (default object name) 


A new Volume Resource object will store property information for the cluster-enabled 
volume, such as start, failover, and failback mode information and load/unload scripts. 
These modes and scripts enable the cluster-enabled volume to function much like an 
independent server; hence, the SERVER portion of its name. The Volume Resource 
object is created in the Cluster container object. 


Continuing with the above example, the new Volume Resource object would be named 
GWVOL1_SERVER.GWCLUSTER. 


IMPORTANT: Notice that the default object names include the underscore (_) character. Some DNS name 
servers cannot resolve object names that include underscore characters. If you have met the system 
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requirements described in “Meeting Software Version Requirements” on page 18, you will be able to rename 
these objects as needed when you cluster enable the volume. 


Cluster-enabling the shared volumes used by GroupWise is highly recommended. Throughout the 
rest of this document, the term "GroupWise volume" means "a cluster-enabled shared volume used 
by GroupWise." 


SYSTEM CLUSTERING WORKSHEET 


Under Item 6: Shared Volumes for GroupWise Administration, list any shared volumes you want to 
use for GroupWise administration purposes. For example, you might have a shared pub: volume with 
a public directory where you install the GroupWise snap-ins to ConsoleOne instead of installing them 
on multiple administrator workstations. You might have a shared apps volume where you create the 
GroupWise software distribution directory. Mark whether or not you want to cluster-enable the 
GroupWise administration volumes. 


Under Item 7: Shared Volume for Domain, specify the name of the shared volume where you will 
create the domain. Mark whether or not you want to cluster-enable the domain volume. Also mark 
whether you will place the post office on the same volume with the domain. 


If you want the post office on a different volume from where the domain is located, under Item 8: 
Shared Volume for Post Office, specify the name of the shared volume where you will create the post 
office. Mark whether or not you want to cluster-enable the post office volume. 


IMPORTANT: Because cluster-enabling the volumes where domains and post offices reside is so strongly 
recommended, this documentation does not include the steps for setting up domains and post offices on non- 
cluster-enabled volumes. If you decide not to cluster-enable GroupWise volumes, you will need to adjust the 
steps presented in this documentation for your system’s specialized needs. Novell Cluster Services does 
provide a GroupWise Mail Server template for use when creating GroupWise Cluster Resource objects instead 
of cluster-enabled Volume Resource objects. 


Ensuring Successful Name Resolution for GroupWise Volumes 


Because you are using cluster-enabled volumes for GroupWise domains and post offices, you must 
ensure that short name resolution is always successful. For example, in ConsoleOne, if you right- 
click a Domain object in the GroupWise View and then click Connect, ConsoleOne must be able 
to resolve the domain database location, as provided in the UNC Path field, to the network address 
of the current, physical location of that domain within your cluster. It is through short name 
resolution that all GroupWise cluster resources (such as domain and post office volumes) are 
accessed and managed in ConsoleOne. 


A client program (such as ConsoleOne) that runs on a Windows* workstation, can be configured 
to use several different short name resolution methods. To see which methods are in use at a 
particular workstation, view the protocol preferences for the Novell Client™ that is installed on the 
Windows workstation: 
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Novell Client for Windows 2000 Properties 2)x) 


Single Sign-on | 
Advanced Settings | Advanced Menu Settings | 
Client | Location Profiles | Advanced Login | Contextless Login | 
Protocol Preferences | Service Location 


Select a protocol and component to configure 


Preferred Network Protocol: = 


Protocol: 


m n 


Protocol component settings- 


MINDS 
M Host File 
MIDNS 

Z SLP 

CO DHCP NDS 


DHCP Settings | Default Capture | 


Component: 


Short name resolution methods that pertain to clustering your GroupWise system are discussed 


below: 


Short Name 
Resolution 
Method 


eDirectory 


Hosts Files 


DNS 


Description 


You can use eDirectory to resolve short names into specific network addresses. However, 
when using eDirectory for short name resolution, you must remember to consider current 
context in the name resolution process. eDirectory short name resolution works only if 
your current context is the same as the context of the eDirectory object you need to 
access. 


Windows uses the following files when performing short name resolution at the 
workstation: 


+ Windows NT/2000/XP: 
\winnt\system32\drivers\etc\hosts 


+ Windows 9.x: 
\novell\client32\nwhosts 


Using these files at the Windows workstation is not a preferred method for TCP/IP name 
resolution (except perhaps for the administrator's workstation). 


However, whenever you cluster-enable a volume, you should add its virtual server to the 
sys:\etc\hosts file of all nodes in the cluster. 


Perhaps the most common short name resolution option is Domain Name Service (DNS). 
As with the HOSTS file, it is good practice to place all of your virtual servers into DNS. 


For short name resolution to work using DNS, the client workstation must either belong to 
the same DNS zone (such as support.novell.com) as the cluster resource, or the cluster 
resource zone must be configured in the client's DNS suffix search path under TCP/IP 
settings for the workstation. 


The underscore ( _ ) character is part of default cluster-related object names. Because it 
is not supported by the DNS RFC, some DNS name servers cannot resolve default 
cluster-related object names. If you are using such a DNS name server on NetWare 5.1, 
make sure you have installed the latest Novell Cluster Services snap-in to ConsoleOne, 
as described in “Updating to the Latest ConsoleOne Snap-In” on page 18, so that you can 
change cluster-related object names as needed to remove the underscore characters. 
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Short Name Description 
Resolution 
Method 


SLP NetWare 6.x and NetWare 5.1 both use Service Location Protocol (SLP) to advertise 
service information across TCP/IP-based networks, which provides short name resolution 
of TCP/IP-based cluster resources within the network. On NetWare 6.x, Novell Cluster 
Services propagates virtual server information into SLP by default. 


On NetWare 5.1, Novell Cluster Services does not propagate virtual server information 
into SLP by default. If you want to propagate virtual server information to SLP on NetWare 
5.1, you can run the (unsupported) CVSBIND utility, which gives you reliable short name 
resolution within your cluster regardless of shortcomings you might encounter with other 
name resolution methods. 


Specific setup instructions for each of these short name resolution methods will be provided in 
Chapter 3, “Setting Up a Domain and Post Office in a Novell Cluster,” on page 37. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 9: IP Address Resolution Methods, mark which methods you want to implement in order 
to resolve the locations stored as UNC paths in ConsoleOne into physical network addresses in your 
system. 


Deciding How to Install and Configure the Agents in a Cluster 
There are several cluster-specific issues to consider as you plan to install the NetWare® MTA and 
POA in your clustered GroupWise system: 


+ “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the 
Cluster” on page 25 


+ “Determining Appropriate Failover Paths for the Agents” on page 27 

+ “Deciding Where to Install the Agent Software” on page 28 

+ “Deciding Whether to Run the Agents in Protected Memory” on page 30 
+ “Planning the NetWare Agent Installation” on page 30 


Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in 
the Cluster 


The Group Wise agents listen on all IP addresses, both primary and secondary, that are bound to 
the server on their specified port numbers. This means that any time there is a possibility of two 
of the same type of agent loading on the same node, it is important that each agent use a cluster- 
unique port number, even though each agent is using a unique secondary IP address. The best way 
for you to avoid port conflicts is to plan your cluster so that each agent in the cluster runs on a 
cluster-unique port. Print out a copy of the “IP Address Worksheet” on page 34 to help you plan 
secondary IP addresses and cluster-unique port numbers for all GroupWise agents. 


The following filled-out version of the IP Address Worksheet illustrates one way this can be done: 
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Domain Information 


MTA MTA MTA 
IP Address MTP Port HTTP Port 


123.45.67.81 7100 7180 


Post Office Information 


Post Office POA POA POA POA 
IP Address C/S Port MTP Port HTTP Port 


| Development | (same as MTA) | as MTA) 677 | maoo Aa 


Po ee ee ca SS 


Internet Agent Information 


Internet oe GWIA MTA MTA Live MTA GWIA 
aoe le Address MTP Port | Remote Port HTTP Port! HTTP Port 

GWIA Domain 123.45.67.83 7110 7677 7183 

MTA 

Internet Agent (same as MTA) 9850 

(GWIA) 


WebAccess Information 


WebAccess Agent | WebAccess MTA MTA WebAccess WebAccess 

IP Address MTP Port | HTTP Port | Agent Port HTTP Port 
WebAccess 123.45.67.84 7120 7184 N/A N/A 
Domain MTA 


WebAccess (same as MTA) N/A N/A 7205 7205 
Agent (same as agent) 
(GWINTER) 


This example places the Development post office on the same node and on the same GroupWise 
volume with the Provol domain; therefore, the Provol MTA and the Development POA can use 
the same secondary IP address. The Manufacturing post office is placed on a different node on a 
different GroupWise volume; so the Manufacturing post office has a different secondary IP 
address. 


The example also illustrates that the MTA, the POA, and the Internet Agent use different port 
numbers for agent ports and HTTP ports. In contrast, the WebAccess Agent uses the same port 
number for the agent port and the HTTP port. 


The example uses default port numbers where possible. For example, the default MTA message 
transfer port is 7100 and the default POA client/server port is 1677. Incrementing port numbers 
are used in the example when multiple components have the same type of ports. For example, port 
numbers 1677 and 1678 are both POA client/server ports and port numbers 7180 through 7184 are 
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all HTTP ports. Incrementing from the default port numbers generates unique, though related, port 
numbers. 


If you are going to set up a GroupWise name server to help GroupWise clients locate their post 
offices, make sure that the default POA port number of 1677 is used somewhere in the cluster. For 
more information, see “Simplifying Client/Server Access with a GroupWise Name Server” in 
“Post Office Agent” in the GroupWise 6.5 Administration Guide. 


IP ADDRESS WORKSHEET 


Fill out the “IP Address Worksheet” on page 34 to help you plan secondary IP addresses and cluster- 
unique port numbers for all GroupWise agents in the cluster. (MTA, POA, Internet Agent, WebAccess 
Agent). 


After you have filled out the IP Address Worksheet, transfer the secondary IP addresses and 
cluster-unique port numbers from the IP Address Worksheet to the System Clustering Worksheet 
and the Agent Clustering Worksheet so that they will be available in the sequence in which you 
will need them as you set up GroupWise in a cluster. 


SYSTEM CLUSTERING WORKSHEET 


If you are setting up a new GroupWise system, under Item 6: Shared Volumes for GroupWise 
Administration, specify secondary IP addresses for your GroupWise administration volumes. 


Under Item 7: Shared Volume for Domain, use the domain MTA secondary IP address from the IP 
Address Worksheet as the domain volume IP address. 


If you are planning the post office on a different volume from the domain, under Item 8: Shared Volume 
for Post Office, use the post office POA secondary IP address from the IP Address Worksheet as the 
post office volume IP address. 


AGENT CLUSTERING WORKSHEET 


Under Item 4: MTA Network Information, transfer the secondary IP address and cluster-unique port 
numbers for the MTA from the IP Address Worksheet to the Agent Clustering Worksheet. 


Under Item 7: POA Network Information, transfer the secondary IP address and cluster-unique port 
numbers for the POA from the IP Address Worksheet to the Agent Clustering Worksheet. 


Determining Appropriate Failover Paths for the Agents 


By default, a Group Wise volume is configured to have all nodes in the cluster in its failover path, 
organized in ascending alphanumeric order. Only one node at a time can have a particular 
GroupWise volume mounted and active. Ifa GroupWise volume’s preferred node fails, the volume 
fails over to the next node in the failover path. You will want to customize the failover path for 
each Group Wise volume based on the fan-out-failover principle. 


When a node fails, its volumes should not all fail over together to the same secondary node. 
Instead, the volumes should be distributed across multiple nodes in the cluster. This prevents any 
one node from shouldering the entire processing load typically carried by another node. In 
addition, some volumes should never have the potential of being mounted on the same node during 
a failover situation. For example, a post office and POA that service a large number of very active 
Group Wise client users should never fail over to a node where another very large post office and 
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heavily loaded POA reside. If they did, users on both post offices would notice a decrease in 
responsiveness of the Group Wise client. 


AGENT CLUSTERING WORKSHEET 


Under Item 3: Domain Failover Path, list the nodes that you want to have in the domain volume failover 
path. The MTA might need to run on any node that the domain volume fails over to. 


If you are planning the post office on a different GroupWise volume from where the domain is located, 
under Item 6: Post Office Failover Path, list the nodes that you want to have in the post office volume 
failover path. The POA might need to run on any node that the post office volume fails over to. 


Deciding Where to Install the Agent Software 


28 


When you install the NetWare MTA and POA in a clustering environment, you can choose 
between two different installation locations: 


Location Description 

sys:\system This is the default location provided by the Agent Installation program. Because 

on each node the agents must be installed on each node where they might need to run during 

in the cluster a failover situation, you would need to do one of the following if you select this 
alternative: 


+ Run the Agent Installation program multiple times in order to install the agent 
software and to create the agent startup files on each node that is on a 
GroupWise volume failover path. 


+ Run the Agent Installation program, then copy the agent software and startup 
files to each node that is on a GroupWise volume failover path. 


system directory If you create a vol:\system directory on a GroupWise volume, the agent software 
on each GroupWise and startup files fail over and back with the domains and post offices that the 
volume agents service. 


Unless you have a very small GroupWise system with all domains and post 
offices on a single GroupWise volume, you will still need to install the agent 
software multiple times, once to each GroupWise volume. 


A simple way to look at the agent location alternatives would be that if you have fewer nodes on 
failover paths than you have GroupWise volumes for domains and post offices, then it would be 
most efficient to install the agent software to the nodes. Conversely, if you have fewer GroupWise 
volumes than you have nodes on failover paths, then it would be most efficient to install the agent 
software to the GroupWise volumes. However, there are issues to consider that extend beyond 
efficiency during installation. 


The following sections can help you choose which installation location would be best for your 
clustered GroupWise system: 


+ “Advantages of a vol:\system Directory on Each GroupWise Volume” on page 29 
¢ “Disadvantages of a vol:\system Directory on Each GroupWise Volume” on page 29 


+ “Recommendation” on page 29 
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Advantages of a vol:\system Directory on Each GroupWise Volume 


Using a vol:\system directory on each GroupWise volume has several advantages: 


¢ If you change information in the agent startup files, you only need to change it in one place, 
not on every node on any GroupWise volume failover path. 


+ Having the agent startup files on the same GroupWise volume as the domain or post office 
makes them easy to find. 


+ When you update the agent software, you only need to update it in one place for a particular 
domain or post office, not on every node on a GroupWise volume failover path. This prevents 
the potential problem of having a domain or post office fail over to a location where a different 
version of the agent software is installed. 


+ Ifyou ever need to add or replace a physical server in the cluster, you only need to install 
NetWare and Novell Cluster Services to the new server, then add that node to the appropriate 
failover paths. No extra Group Wise configuration is necessary because there are no 
sys:\system dependencies for the GroupWise agents. 


+ If you want to back up the GroupWise software, you do not have to include the sys:\system 
directory in the backup. 


Disadvantages of a vol:\system Directory on Each GroupWise Volume 


Recommendation 


Installing the agents on a GroupWise volume does have some disadvantages: 


+ GroupWise administrators who are used to the Group Wise agents being installed in 
sys:\system might be confused by not finding them there in the clustered GroupWise system. 


+ You must remember where you installed the GroupWise agents when you update the agent 
software. Accidently installing a GroupWise Support Pack to the default location of 
sys:\system would not have the desired results if the original agent software was installed to 
the vol:\system directory on a GroupWise volume. 


Whichever method you choose, be consistent throughout the entire cluster. Either put all the 
Group Wise agents on the GroupWise volumes with the domains and post offices they service, or 
put them all in sys:\system directories. If you put them on GroupWise volumes, make sure there 
are no agent files in sys:\system directories to confuse the issue at a later time. 


Even if you choose to install the agents to multiple sys:\system directories, you can still store the 
agent startup files on the GroupWise volumes. The significant advantage of this approach is that 
you only have one startup file to modify per agent. 


AGENT CLUSTERING WORKSHEET 


Under Item 1: Agent Installation Location, mark whether you will install the agent software to a 
vol:\system directory on a GroupWise volume or to sys:\system on each node in the cluster. If 
necessary, specify where the agent startup files will be stored. 


Under Item 2: Domain Name, transfer the domain name and location from the System Clustering 
Worksheet to the Agent Clustering Worksheet. 


Under Item 5: Post Office Name, transfer the post office name and location from the System Clustering 
Worksheet to the Agent Clustering Worksheet. 
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Deciding Whether to Run the Agents in Protected Memory 


Ona NetWare server, using protected memory allows you to create isolated memory spaces where 
NLM programs can run without affecting other NLM programs running on the same node. This 
contributes to the high availability of the cluster. Using protected memory has the following 
advantages: 


+ When using protected memory, the node can restart a specific memory space if any NLM 
program within that memory space abends. This allows for recovery without failing the entire 
node, which enhances both up time and database integrity. 


+ Using protected memory gives you the ability to unload a single instance of an agent, rather 
than all instances. 


¢ Ifyou use protected memory, you can run the agents in active/active mode, rather than active/ 
passive mode. 


If you have any possibility of the same type of GroupWise agent loading multiple times on any 
node in the cluster, you must use protected memory so that you can unload agents individually. 
Check your failover paths (Agent Clustering Worksheet items 3 and 6) for failover combinations 
where multiple instances of the same type of agent might need to run on the same node. 


Protected memory does result in higher memory utilization (about 5% to 10%) and a slight 
performance penalty. Make sure your nodes have sufficient memory to handle the number of 
memory spaces that might reside on them. If you load the MTA and the POA in different memory 
spaces, the agent engine (gwenn4.nlm) will load twice on the node. Remember to provide memory 
for any GroupWise volumes that could fail over to a node, in addition to that node’s regular 
processing load. 

IMPORTANT: We strongly recommend that you run the agents in protected memory, with one agent per 
memory space, for optimum stability. 


AGENT CLUSTERING WORKSHEET 


Under Item 8: Load Agents in Protected Memory?, mark whether or not you need to run the 
GroupWise agents in protected memory. 


If you will use protected memory, provide one or two unique protected memory space names. If you 
will create the domain and post office on the same GroupWise volume, the MTA and POA can use the 
same memory space, although this is not recommended. If you will create the domain and post office 
on different GroupWise volumes, the MTA and POA must use different memory spaces. 


If you will use protected memory, a user name and password for the POA to use to access its post 
office volume might be required, depending on the version of NetWare you are using. 


Provide a user name and password if you are using the following versions of NetWare: 

+ NetWare 5.1 Support Pack 2 or earlier 

¢ Initial release of NetWare 6 

A user name and password are no longer needed on the following later versions of NetWare. 
+ NetWare 5.1 Support Pack 3 or later 

+ NetWare 6 Support Pack 1 or later 


Planning the NetWare Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the GroupWise NetWare agents are the same in a clustering 
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environment as for any other environment. Review “Planning the GroupWise Agents”, then print 
and fill out the “GroupWise Agent Installation Worksheet” in “Installing GroupWise Agents” in 
the GroupWise 6.5 Installation Guide for each location where you will install the NetWare MTA 
and/or POA. 


Fill out the NetWare Agent Worksheet, taking into account the following cluster-specific issues: 


GROUPWISE AGENT INSTALLATION WORKSHEET 


Under Item 2: Agents and Locations, mark POA Local to Post Office and MTA Local to Domain. Ina 
clustering environment, a domain or post office and its agent must reside on the same GroupWise 
volume in order to fail over together. 


Under Item 3: Installation Path, take into account your decision based on “Deciding Where to Install 
the Agent Software” on page 28. 


Under Item 4: Configure GroupWise Agents for Clustering, mark Yes. This will cause the Agent 
Installation program to customize the agent startup files for clustering. 


Under Item 6: Domains and Item 7: Post Offices, refer to the Domain and Post Office Worksheets you 
filled out during “Planning a New Clustered Domain” on page 20 and “Planning a New Clustered Post 
Office” on page 21, and to the IP Address Worksheet you completed during “Planning Secondary IP 
Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 25. 


Under Item 10: Launch GroupWise Agents Now, mark No. You will configure the agents to run in 
protected mode later. 


IMPORTANT: Do not install the NetWare agent software until you are instructed to do so in Chapter 3, “Setting 
Up a Domain and Post Office in a Novell Cluster,” on page 37. 


Continue with Chapter 3, “Setting Up a Domain and Post Office in a Novell Cluster,” on page 37. 
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GroupWise Clustering Worksheets 


¢ “System Clustering Worksheet” on page 32 
+ “IP Address Worksheet” on page 34 


+ “Agent Clustering Worksheet’ on page 35 


System Clustering Worksheet 


Item 


1) Software Version Updates 


Explanation 


Mark any updates the nodes in your cluster need in order to meet the system 


for Cluster: 


+ NetWare 5.1 Support Pack 3 or higher 


¢ Latest ConsoleOne Snap-In for Novell 


Cluster Services 


2) eDirectory Tree for Cluster: 


3) Cluster Name: 
Cluster IP Address: 


4) Cluster Context: 


5) Nodes in Cluster 


6) Shared Volumes for GroupWise 
Administration: 


Cluster Enabled? 


+ Yes (highly recommended) 


Cluster volume IP addresses 


+ No 


GroupWise Administration Snap-ins to 


ConsoleOne 
+ public directory 


+ Other 


GroupWise Software Distribution Directory 


+ \grpwise\software directory 


+ Other 
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requirements for a GroupWise system in a cluster. 


For more information, see “Meeting Software Version Requirements” on 
page 18. 


Record the eDirectory tree where you created the new Novell Cluster object 
when you installed Novell Cluster Services. 


For more information, see “Installing Novell Cluster Services” on page 19 


Record the name of the new NetWare Cluster object that you created for 
your GroupWise system. Also record the virtual IP address of the cluster that 
will remain constant regardless of which node is currently active. 


For more information, see “Installing Novell Cluster Services” on page 19. 
Record the full context where you created the new NetWare Cluster object. 


For more information, see “Installing Novell Cluster Services” on page 19. 


List the nodes that are part of the cluster that you set up for your GroupWise 
system. 


For more information, see “Installing Novell Cluster Services” on page 19. 


Specify the names (cluster_volume) of the shared volumes where the 
GroupWise administration snap-ins to ConsoleOne and the GroupWise 
software distribution directory will reside. 


For cluster-enabling, specify the IP addresses of the virtual servers 
(volume_SERVER.cluster) to which the cluster-enabled volumes are tied. 


For more information, see “Deciding Whether to Cluster-Enable the Shared 
Volumes Used by GroupWise” on page 21. 


Item 


7) Shared Volume for Domain: 


Cluster Enabled? 


+ Yes (highly recommended) 


Cluster volume IP address 


+ No 


Post Office on Same Volume as Domain? 


+ Yes 

« No 

8) Shared Volume for Post Office: 
Cluster Enabled? 


+ Yes (highly recommended) 


Cluster volume IP address 


+ No 


9) IP Address Resolution Methods: 
+ eDirectory 

¢ hosts file 

¢ DNS 

+ SLP (highly recommended) 

10) Domain Name: 


Domain Database Location: 


11) Post Office Name: 


Post Office Database Location: 


12) Document Storage Area Location: 


+ At the post office 

+ Outside the post office 

+ Separate post office 
Document Storage Area Access 


+ POA /user startup switch setting 


+ POA /password startup switch setting 


Explanation 


Specify the name (c/uster_volume) of the shared volume where the 
GroupWise domain will reside. 


For cluster-enabling, specify the IP address of the virtual server 
(volume_SERVER.cluster) to which the cluster-enabled volume is tied. 


For more information, see “Planning a New Clustered Post Office” on 
page 21 and “Deciding Whether to Cluster-Enable the Shared Volumes 
Used by GroupWise” on page 21. 


Specify the name (c/uster_volume) of the shared volume where the 
GroupWise post office will reside. 


For cluster-enabling, specify the IP address of the virtual server 
(volume_SERVER.cluster) to which the cluster-enabled volume is tied. 


For more information, see “Planning a New Clustered Post Office” on 
page 21 and “Deciding Whether to Cluster-Enable the Shared Volumes 
Used by GroupWise’ on page 21. 


Mark the short name address resolution methods you want to implement to 
ensure that the UNC paths stored in ConsoleOne can be successfully 
resolved into physical network addresses. 


For more information, see “Ensuring Successful Name Resolution for 
GroupWise Volumes” on page 23 


Specify a unique name for the domain. Specify the directory on the 
GroupWise volume where you want to create the new domain. 


For more information, see “Planning a New Clustered Domain” on page 20. 


Specify a unique name for the post office. Specify the directory on the 
GroupWise volume where you want to create the post office. 


For more information, see “Planning a New Clustered Post Office” on 
page 21. 


If you need a library for a clustered post office, mark where you want to 
create its document storage area and provide a directory if necessary. 


For more information, see “Planning a New Library for a Clustered Post 
Office” on page 21. 
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IP Address Worksheet 


Domain Information 


MTA MTA MTA 
IP Address MTP Port HTTP Port 


Post Office Information 


Post Office POA POA POA POA 
IP Address C/S Port MTP Port HTTP Port 


Internet Agent Information 


Internet Agent GWIA MTA MTA MTA GWIA 
IP Address MTP Port Live Remote Port HTTP Port HTTP Port 


| GWIA Domain MTA | Domain Ma 


Internet = a 
(GWIA) 


WebAccess Information 


WebAccess Agent | WebAccess MTA MTA WebAccess Agent WebAccess 

IP Address MTP Port HTTP Port Port HTTP Port 
WebAccess N/A N/A 
Domain MTA 


WebAccess Agent | (same) N/A N/A 
(GWINTER) 
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Agent Clustering Worksheet 


Item 


1) agent installation location: 
¢ vol:\system on the GroupWise volume 


¢ sys:\system on each node 


Consolidate multiple startup files on GroupWise 
volume? 


2) Domain Name: 
Domain Location: 


3) Domain Failover Path: 


4) MTA Network Information: 
+ MTA IP address 

+ MTA message transfer port 
+ MTA HTTP port 

5) Post Office Name: 


Post Office Location: 


6) Post Office Failover Path: 


7) POA Network Information: 
+ POA IP address 

+ POA client/server port 

+ POA message transfer port 


+ POA HTTP port 


8) Load Agents in Protected Memory? 
« No 


+ Yes 
MTA protected address space 
POA protected address space 
POA /user startup switch setting 


POA /password startup switch setting 


Explanation 


Mark the location where you will install the agent software. 


If necessary, specify the location where you will consolidate multiple 
agent startup files on a GroupWise volume. 


For more information, see “Deciding Where to Install the Agent Software” 
on page 28. 


Transfer this information from the System Clustering Worksheet (item 
10). 


List other nodes in the cluster where the GroupWise domain and its MTA 
could fail over. 


For more information, see “Determining Appropriate Failover Paths for 
the Agents” on page 27. 


Gather the MTA network address information from the “IP Address 
Worksheet” on page 34. 


For more information, see “Planning Secondary IP Addresses and 
Cluster-Unique Port Numbers for Agents in the Cluster” on page 25. 


Transfer this information from the System Clustering Worksheet (item 11). 


List other nodes in the cluster where the GroupWise post office and its 
POA could fail over. 


For more information, see “Determining Appropriate Failover Paths for 
the Agents” on page 27. 


Gather the POA network address information from the “IP Address 
Worksheet” on page 34. 


For more information, see “Planning Secondary IP Addresses and 
Cluster-Unique Port Numbers for Agents in the Cluster” on page 25. 


Mark whether you need to run the agents in protected memory. If so, 
specify a unique address space for each agent. For the POA, specify a 
user name and password if required by your version of NetWare. 


IMPORTANT: We strongly recommend that you run the agents in 
protected memory, with one agent per memory space, for optimum 
stability. 


For more information, see “Deciding Whether to Run the Agents in 
Protected Memory” on page 30. 
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Setting Up a Domain and Post Office in a Novell 
Cluster 


You should have already reviewed “Planning GroupWise in a Novell Cluster” on page 17 and 
filled out the “System Clustering Worksheet” on page 32, the “IP Address Worksheet” on page 34, 
and the “Agent Clustering Worksheet” on page 35. You are now ready to complete the following 
tasks to set up GroupWise® in a clustering environment: 


+ “Preparing the Cluster for GroupWise” on page 37 

+ “Setting Up a New GroupWise System in a Cluster” on page 40 

+ “Creating a New Secondary Domain in a Cluster” on page 42 

+ “Creating a New Post Office in a Cluster” on page 43 

+ “Installing and Configuring the MTA and the POA in a Cluster” on page 44 
+ “Testing Your Clustered GroupWise System” on page 53 

+ “Managing Your Clustered GroupWise System” on page 54 

+ “What’s Next” on page 58 

+ “Clustering Quick Checklists” on page 59 


Preparing the Cluster for GroupWise 


After you have installed Novell® Cluster Services™, as described in Novell Cluster Services 
Overview and Installation, complete the following tasks to prepare the cluster for your Group Wise 
system: 


+ “Ensuring Required Software Versions” on page 37 
+ “Cluster-Enabling Shared Volumes for Use with GroupWise” on page 37 
+ “Configuring Short Name Resolution” on page 38 


Ensuring Required Software Versions 
Double-check each node in the cluster to make sure it meets the requirements described in 
“Meeting Software Version Requirements” on page 18. 

Cluster-Enabling Shared Volumes for Use with GroupWise 


To cluster-enable a shared volume for use with Group Wise: 


1 Select a System Clustering Worksheet item (6, 7, or 8) where you selected Yes under Cluster 
Enabled?. 
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2 Complete the steps in the applicable section of Novell Cluster Services Overview and 
Installation for your version of NetWare®: 


+ NetWare 6.x: “Cluster Enable Pools and Volumes” 
+ NetWare 5.1: “Cluster-Enable Volumes ” 


The System Clustering Worksheet provides the volume to cluster-enable for use the 
Group Wise, the cluster-enabled volume IP address, and the failover path for the Group Wise 
volume. 


For a review of the new Novell eDirectory™ objects that are created when you cluster-enable 
a shared volume, see “Deciding Whether to Cluster-Enable the Shared Volumes Used by 
GroupWise” on page 21. 


If you have installed the latest version of ConsoleOne® and the Novell Cluster Services snap- 
in, as described in “Updating to the Latest ConsoleOne Snap-In” on page 18, you will be able 
to rename the cluster-related objects in case your DNS name server cannot resolve object 
names that include the underscore (_) character. 


3 Repeat Step | and Step 2 above for the other shared volumes on your System Clustering 
Worksheet that need to be cluster-enabled. 


4 Continue with “Configuring Short Name Resolution” on page 38. 


Configuring Short Name Resolution 


eDirectory 


To ensure that GroupWise volumes are always locatable, configure the short name resolution 
methods that you want to rely on for GroupWise (System Clustering Worksheet item 9): 


+ “eDirectory” on page 38 
+ “Hosts Files” on page 39 
+ “DNS” on page 39 
+ “SLP” on page 40 


After configuring your selected short name resolution methods, continue with the task you need to 
perform: 


+ “Setting Up a New GroupWise System in a Cluster” on page 40 
+ “Creating a New Secondary Domain in a Cluster” on page 42 


+ “Creating a New Post Office in a Cluster” on page 43 


Most commonly, you will use eDirectory to resolve the UNC path of a volume into its network 
address. For example, on the workstation where you run ConsoleOne, you would need to map a 
drive to the location of a domain directory so that ConsoleOne can access the domain database. 
You could use a map command as shown in the example below: 


Syntax: 
map drive: = .cluster_ volume.context 
Example: 
map m: = .GWCLUSTER GWVOL1.GWServers 
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Hosts Files 


DNS 


When specifying the map commands, use System Clustering Worksheet item 3 for cluster. Use 
System Clustering Worksheet item 7 or 8 for each volume where a domain or post office resides. 
Use System Clustering Worksheet item 4 for context. 


Because each GroupWise volume where you plan to create a domain or post office has been 
associated with a virtual server, you should add lines for the new virtual servers to one or more of 
the following files as needed: 


+ NetWare: 
sys:\etc\hosts 
(on all nodes in the cluster; recommended) 


+ Windows NT/2000: 
\winnt\system32\drivers\etc\hosts 
(on the administrator’s workstation only; optional) 


+ Windows 9.x: 
\novell\client32\nwhosts 
(on the administrator’s workstation only; optional) 


The lines you add to a hosts file could look similar to the following example (all on one line, of 
course): 


Syntax: 
IP_address cluster_volume_SERVER. context 
cluster_volume_SERVER 


Remember that cluster_volume_SERVER represents the name of the virtual server created when 
you cluster-enabled the volume. 


Example: 
123.45.67.81 
gwcluster gwvoll SERVER.gwcluster.com 
gwcluster_gwvoll SERVER 


When specifying the lines in the hosts files, use System Clustering Worksheet item 7 or 8 for each 
IP_address and volume where a domain or post office resides. Use System Clustering Worksheet 
item 3 for cluster. Use System Clustering Worksheet item 4 for context. 


Because each GroupWise volume where you plan to create a domain or post office has been 
associated with a virtual server, you should add all your new virtual servers to DNS. Then you 
could use a map command as shown in the example below (all on one line, of course): 


Syntax: 
map drive: = 
\\volume_SERVER.cluster.com\volume 


Remember that volume SERVER represents the name of the Volume Resource object created 
when you cluster-enabled the volume. A cluster-enabled volume can function like a server, as 
these commands illustrate. 


Example: 
map m: = 
\\gwvoll_SERVER.gwcluster.com\gwvoll 
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SLP 


Or, if the ConsoleOne workstation is in the same DNS domain as the GroupWise volume: 


Syntax: 

map drive: = \\volume_SERVER\volume 
Example: 

map m: = \\gwvoll_ SERVER\gwvoll 


When specifying the map commands you will need, use System Clustering Worksheet item 7 or 8 
for each volume where a domain or post office resides. Use System Clustering Worksheet item 3 
for cluster. 


On NetWare 6.x, Novell Cluster Services automatically propagates virtual server information into 
SLP and provides the most reliable name resolution. 


On NetWare 5.1, Novell Cluster Services does not propagate virtual server information into SLP 
by default. If you want to use SLP for name resolution on NetWare 5.1, you must download the 
(unsupported) CVSBIND utility from the Technical Information Document NWCS Bindery Tool 
(http://support.novell.com/cgi-bin/search/searchtid.cgi?/2957434.htm). Install CVSBIND 
according to the instructions included with the download, then determine the server-specific 
commands you will need to use with CVSBIND. 


Syntax: 
cvsbind add cluster volume SERVER ip address 
cvsbind del cluster_volume_SERVER ip address 


Remember that cluster_volume_SERVER represents the name of the virtual server created when 
you cluster-enabled the volume. 


Example: 
cvsbind add gwcluster gwvoll SERVER 123.45.67.81 
cevsbind del gwcluster gwvoll SERVER 123.45.67.81 


Later, in “Modifying the Volume Resource Load Script for the Agents” on page 46 and 
“Modifying the Volume Resource Unload Script for the Agents” on page 48, you will need to add 
the cvsbind commands to the load and unload scripts for GroupWise volume resources. 
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The Group Wise Installation Advisor walks you through setting up the primary domain and an 
initial post office in the primary domain. You might be creating your primary domain and initial 
post office on the same GroupWise volume or on two different volumes. After you have created 
the primary domain and initial post office and installed the GroupWise agents, you can create 
additional secondary domains and post offices as needed. 


To set up the primary domain and initial post office for a new GroupWise system in a clustering 
environment: 


1 Ifnecessary, map a drive to each GroupWise administration volume (System Clustering 
Worksheet item 6). 


2 Map a drive to the GroupWise volume for the domain (System Clustering Worksheet item 7) 
and, if needed, to the GroupWise volume for the post office (System Clustering Worksheet 
item 8), where the primary domain and the initial post office for your new GroupWise system 
will be created. 


GroupWise 6.5 Interoperability Guide 


The GroupWise volume name will be cluster_volume. For assistance with mapping a drive to 
a cluster-enabled volume, see “Configuring Short Name Resolution” on page 38. 


3 Manually create the domain directory (System Clustering Worksheet item 10) and the post 
office directory (System Clustering Worksheet item 12). 


This step is not required, but in a clustered environment, the following step will be easier if 
the domain directory already exists. 


4 Run the GroupWise Installation Advisor to set up your initial GroupWise system, following 
the steps provided in “Setting Up a Basic GroupWise System on NetWare or Windows” in 
“Installing a Basic GroupWise System” in the GroupWise 6.5 Installation Guide. Keep in 
mind the following cluster-specific details: 


+ When you specify the ConsoleOne directory and the software distribution directory, be 
sure to browse to each location through the Group Wise volume accessed in Step | above. 


+ When you specify the domain directory and post office directory, be sure to browse 
through the Group Wise volume accessed in Step 2 to select the directory created in Step 3 
above. 


¢ For the post office link type, select TCP/IP Link. 


+ When providing the MTA and POA network address information, use the Agent 
Clustering Worksheet that you filled out during “Deciding How to Install and Configure 
the Agents in a Cluster” on page 25. The information you provide will be used to 
configure the MTA and POA objects in the domain and post office even though you have 
not yet installed the agent software. 


¢ Do not worry about creating users in the post office at this time. 


+ Inthe Summary dialog box, the domain directory and post office directory that you 
browsed to should display as UNC paths using the virtual server name with the 
Group Wise volume. 


GroupWise System Setup [x] 


Summa 
Novell. ry 
System name: Corporate 
Tree: CORP_TREE 
Domain name: Provo 
Domain context: GroupWise.Provo 
Domain directory: \GW-CLUSTER_GWVOL_SERVER\ 
Domain time zone: (GMT-07:00) Mountain Time (US & © 


Domain language: English - US 

Post office name: Development 

Post office context:  GroupWWise.Provo 

Post office directory: \WGW-CLUSTER_GWVOL_SERVER\ 
Post office time zone: (GMT-07:00) Mountain Time (US &C ~ 


Ifthe above information is correct, click Next to create your 
GroupWise system. To correct any information, click Back until 
you reach the appropriate page. 


Cancel Fimer 


5 When you have finished creating the primary domain and the initial post office, continue with 
installing the GroupWise Agents, starting with Step 4 on page 45 in “Installing and 
Configuring the MTA and the POA in a Cluster” on page 44. 
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Creating a New Secondary Domain in a Cluster 
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After you have set up the primary domain and initial post office, as described in “Setting Up a New 
Group Wise System in a Cluster” on page 40, you can create additional secondary domains as 
needed. 


To create a new secondary domain in a clustering environment: 


1 Map a drive to the GroupWise volume for the domain (System Clustering Worksheet item 7) 
where the new secondary domain will be created. 


The GroupWise volume name will be cluster_volume. For assistance with mapping a drive to 
a cluster-enabled volume, see “Configuring Short Name Resolution” on page 38. 


2 Manually create the domain directory (System Clustering Worksheet item 10). 


This step is not required, but in a clustered environment, Step 5 will be easier if the domain 
directory already exists. 


3 Ifyou selected vol:\system on GroupWise volume as the agent installation location (under 
Agent Clustering Worksheet item 1), create the vo/:\system directory on the Group Wise 
volume accessed in Step 1. 


or 
If you selected sys:\system on each node, decide which node you will install the agents to first. 


4 In ConsoleOne, connect to the primary domain in your GroupWise system, as described in 
“Connecting to a Domain” in “Domains” in the GroupWise 6.5 Administration Guide. 


5 Create the new domain, following the steps provided in “Creating the New Domain” in 
“Domains” in the GroupWise 6.5 Administration Guide. Keep in mind the following cluster- 
specific details: 


+ Use the Domain Worksheet you filled out during “Planning a New Clustered Domain” on 
page 20 to fill in the fields in the Create GroupWise Domain dialog box. 


+ Inthe Domain Database Location field, be sure to browse through the drive you mapped 
in Step | to the domain directory you created in Step 2 above. 


+ Inthe Link to Domain field, link the new domain to the primary domain of your 
Group Wise system. 


+ The Configure Link option is selected by default. Select TCP/IP Link to the Other 
Domain. Refer to the Agent Clustering Worksheet that you filled out during “Planning 
Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on 
page 25 for the secondary IP address and cluster-unique port numbers that you need to 
specify in order to configure the link. 


6 Use the Link Configuration tool to change the links from the new domain to all other domains 
in the cluster to direct TCP/IP links, following the steps provided in “Changing the Link 
Protocol between Domains to TCP/IP” in “Message Transfer Agent” in the GroupWise 6.5 
Administration Guide. 


Although a complete mesh link configuration is the most efficient, it might not be feasible in 
all situations. Set up as many direct TCP/IP links as possible for best MTA performance in the 
cluster. 


7 Make sure you are still connected to the primary domain. 


8 Rebuild the domain database for the new domain, following the steps provided in “Rebuilding 
Domain or Post Office Databases” in “Databases” in the GroupWise 6.5 Administration 
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Guide. Be sure to browse to the database location (under System Clustering Worksheet item 
10) through the virtual server that was created when you cluster-enabled the Group Wise 
volume. 


The database rebuild is necessary in order to transfer the MTA configuration information and 
the domain link information into the secondary domain database, because the MTA for the 
new domain is not yet running. 


Continue with “Creating a New Post Office in a Cluster” on page 43. 


Creating a New Post Office in a Cluster 


You can create a new post office on the same GroupWise volume where its domain resides or on 
a separate GroupWise volume. If the post office and its domain are on the same Group Wise 
volume, they fail over together. If they are on separate GroupWise volumes, they fail over 
separately. 


To create a new post office in a clustering environment: 


1 


4 


If you selected Yes for Post Office on Same Volume as Domain? (under System Clustering 
Worksheet item 7), map a drive to the GroupWise volume for the domain (System Clustering 
Worksheet item 7). 


or 


Map a drive to the GroupWise volume for the post office (System Clustering Worksheet item 
8). 


The GroupWise volume name will be cluster_volume. For assistance with mapping a drive to 
a cluster-enabled volume, see “Configuring Short Name Resolution” on page 38. 


Manually create the post office directory (System Clustering Worksheet item 12). 


This step is not required, but in a clustered environment, Step 4 will be easier if the post office 
directory already exists. 


In ConsoleOne, connect to the GroupWise domain where you want to create the new post 
office, as described in “Connecting to a Domain” in “Domains” in the GroupWise 6.5 
Administration Guide. 


Create the new post office, following the steps provided in “Creating the New Post Office” in 
“Post Offices” in the GroupWise 6.5 Administration Guide. Keep in mind the following 
cluster-specific details: 


+ Use the Post Office Worksheet you filled out during “Planning a New Clustered Post 
Office” on page 21 to fill in the fields in the Create GroupWise Post Office dialog box. 


+ Inthe Post Office Database Location field, be sure to browse through the drive you 
mapped in Step | to the post office directory you created in Step 2 above. 


+ Ifyou want to create a library at the post office (System Clustering Worksheet item 14), 
select Create Library. 


+ The Configure Link option is selected by default. Select TCP/IP Link from Domain to 
New Post Office. Refer to the Agent Clustering Worksheet that you filled in during 
“Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the 
Cluster” on page 25 for the secondary IP address and cluster-unique port numbers that 
you need to specify in order to configure the link. 


Right-click the new Post Office object, then click Properties. 
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6 Click GroupWise > Post Office Settings; in the Access Mode field, select Client/Server Only. 
7 Right-click the new POA object, then click Properties. 


On the POA Agent Settings and Scheduled Events pages, you might want to specify unique 
times for the following POA activities to prevent multiple POAs from performing the same 
activities on the same node at the same time during a failover situation: 


¢ Start User Upkeep 

+ Generate Address Book for Remote 
¢ Enable QuickFinder Indexing 

+  Mailbox/Library Maintenance Event 


For more information about these repetitive POA activities, see “Performing Nightly User 
Upkeep”, “Regulating Indexing”, and “Scheduling Database Maintenance” in “Post Office 
Agent” in the GroupWise 6.5 Administration Guide. 


8 Make sure you are still connected to the domain that owns the new post office. 


9 Rebuild the post office database for the new post office, following the steps provided in 
“Rebuilding Domain or Post Office Databases” in “Databases” in the GroupWise 6.5 
Administration Guide. Be sure to browse to the database location (under System Clustering 
Worksheet item 11) through the virtual server that was created when you cluster-enabled the 
Group Wise volume. 


The database rebuild is necessary in order to transfer the POA configuration information and 
the post office link information into the post office database, because the POA for the new 
post office is not yet running. 


10 Ifyou want to create a library (System Clustering Worksheet item 14) for the clustered post 
office, follow the steps in “Setting Up a Basic Library” or “Setting Up a Full-Service Library” 
in “Libraries and Documents” in the GroupWise 6.5 Administration Guide, after you have 
completely finished setting up the clustered post office. 


11 Continue with “Installing and Configuring the MTA and the POA in a Cluster” on page 44. 
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After you have created a new domain and/or post office, you are ready to install and configure the 
GroupWise agents. Complete all the tasks below if you are setting up a new GroupWise system or 
if you have created a new GroupWise volume where you want to install the agent software: 


¢ “Installing the Agent Software in a Cluster” on page 45 
¢ “Editing Clustered Agent Startup Files” on page 45 
+ “Configuring the GroupWise Volume Resource to Load and Unload the Agents” on page 46 


Under some circumstances, the agent software has already been installed and you simply need to 
create a new startup file specific to the new domain or post office. For example: 


+ You have created a new domain and/or post office on a GroupWise volume where the agent 
software is already installed in the vo/:\system directory of the GroupWise volume. 


+ In your GroupWise system, the agent software is already installed to multiple sys:\system 
directories. 


In these circumstances, follow the instructions in “Setting Up New Instances of the Agents without 
Installing the Agent Software” on page 51 instead of completing the tasks above. 
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Installing the Agent Software in a Cluster 
To install the MTA and the POA: 


1 Map a drive to the GroupWise volume for the domain (Agent Clustering Worksheet item 2) 
or the post office (Agent Clustering Worksheet item 5). 


The GroupWise volume name will be cluster_volume. For assistance with mapping a drive to 
a cluster-enabled volume, see “Configuring Short Name Resolution” on page 38. 


2 Ifyou selected vol:\system on GroupWise volume as the agent installation location (under 
Agent Clustering Worksheet item 1), create the vo/:\system directory on the Group Wise 
volume accessed in Step 1. 


or 
If you selected sys:\system on each node, decide which node you will install the agents to first. 


3 Start the Agent Installation program, following the steps provided in “Installing the NetWare 
Agent Software” in “Installing GroupWise Agents” in the GroupWise 6.5 Installation Guide. 


4 Install the NetWare® agents, keeping in mind the following cluster-specific details: 


+ Use the NetWare Agent Clustering Worksheet that you filled out during “Planning the 
NetWare Agent Installation” on page 30 to fill in the fields during the agent installation 
process. 


+ In the Installation Path dialog box, be sure to browse through the drive you mapped in 
Step 1 to the location you chose in Step 2 above. Also select Configure GroupWise 
Agents for Clustering. 


+ Inthe Domains / Post Offices dialog box, click Add for each domain and post office that 
the agents will service. In the Path to Database field, be sure to browse through the drive 
you mapped in Step | above to the domain directory or the post office directory. In the 
HTTP Port field, specify the cluster-unique HTTP port planned for each agent (under 
Agent Clustering Worksheet items 4 and 7). 


+ In the Installation Complete dialog box, do not select Launch GroupWise Agents Now. 
You will configure the agents to launch in protected mode later. 


5 If you need to install the agents to sys:\system on multiple nodes in the cluster: 
5a Repeat Step 4, mapping new drives as needed. 


5b Ifyou selected Yes for Consolidate Multiple Startup Files on GroupWise Volume? (under 
Agent Clustering Worksheet item 1), copy one complete set of agent startup files and the 
grpwise.ncf file to the planned location, then delete all agent startup files, as well as the 
grpwise.ncf file, from the sys:\system directories to avoid future confusion. 


The grpwise.ncf file includes a load command for each instance of each agent. You will 
use this information later when you create the load and unload scripts for the volume 
resources. 


6 Continue with “Editing Clustered Agent Startup Files” on page 45. 


Editing Clustered Agent Startup Files 


By default, the Agent Installation program creates agent startup files in the agent installation 
directory. Each MTA startup file is named after the domain it services, with a .mta extension. Each 
POA startup file is named after the post office it services, with a .poa extension. 


Setting Up a Domain and Post Office in a Novell Cluster 45 


Because you selected Configure GroupWise Agents for Clustering during installation, the Agent 
Installation program set the MTA /home startup switch and the POA /home startup switch using 
the format: 


volume: \directory 
so that the startup files are valid no matter which node the agents are currently running on. 


The Agent Installation program also adds a /cluster startup switch to POA startup files to ensure 
that GroupWise clients detect the clustering environment and try more persistently to reconnect in 
a failover, failback, or migration situation. 


One additional manual modification of POA startup files is required for robust functionality in a 
clustering environment. Uncomment the /ip startup switch and provide the secondary IP address 
of the GroupWise volume where the post office is located (Agent Clustering Worksheet item 7). 
This information is available to the POA in its eDirectory object properties. However, in some 
failover situations, reconnection to the MTA is improved when the information is immediately 
available to the POA in its startup file. 


If you are running the POA in protected memory and your version of NetWare requires it, add the 
/user and /password startup switches (under Agent Clustering Worksheet item 8) in order to 
provide a user name and password that the POA can use to access its post office volume. 


If the POA needs to access a remote document storage area, add the /user and /password startup 
switches (under System Clustering Worksheet item 12) in order to provide a user name and 
password that the POA can use to access the volume where the document storage area resides. As 
an alternative to startup switches, you can assign the POA object all rights except Supervisor and 
Access control, as long as the remote document storage area is located in the same tree with the 
post office. 


Configuring the GroupWise Volume Resource to Load and Unload the Agents 


The properties of the Volume Resource object define how the GroupWise volume functions within 
the cluster, how NLM programs are loaded and unloaded, and how failover and failback situations 
are handled. At this point, you might have one volume resource with a domain and post office on 
it, or you might have two volume resources, one for the domain and one for the post office. 
Complete the following tasks for each volume resource: 


+ “Modifying the Volume Resource Load Script for the Agents” on page 46 
¢ “Modifying the Volume Resource Unload Script for the Agents” on page 48 
¢ “Setting the Failover Path and Policies for the Agents” on page 49 
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The volume resource load script executes whenever the GroupWise volume comes online. 
To set up the load script: 
1 In ConsoleOne, browse to and select the Cluster object. 
If necessary, click View > Console View to display its contents. 


2 Right-click the Volume Resource object (volume_SERVER), then click Properties > Load to 
display the default volume resource load script for the GroupWise volume. 


3 Make the following changes to the default load script: 
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+ Remove the trustmig command. It is not necessary to migrate trustees for a GroupWise 
volume. Removing this line helps the load script to execute faster. 


+ On NetWare 5.1, if you selected SLP as a short name resolution method, add the cvsbind 
add command for the GroupWise volume to the load script. 


cvsbind add cluster _volume_SERVER IP address 


+ Ifyou selected vol:\system on GroupWise volume as the agent installation location 
(Agent Clustering Worksheet item 1), add a search add command to add the new 
vol:\system directory to the server search path. 


search add volume:\system 


+ If you selected sys:\system on each node as the installation location (Agent Clustering 
Worksheet item 1) but you are storing the agent startup files on the GroupWise volume, 
add that location to the server search path. 


+ Ifyou selected No under Load Agents in Protected Memory? (Agent Clustering 
Worksheet item 8), add the following abend recovery options: 


set auto restart after abend = 2 

set auto restart after abend delay time = 0 
set auto restart down timeout = 60 

set developer option = off 


These settings provide the best possible handling of GroupWise databases in the event 
that an abend should occur within the cluster when the agents are not running in protected 
memory. 


+ Transfer the agent load commands from the grpwise.ncf file into the load script. Use 
Ctrl+C to copy and Ctrl+V to paste text into the load script page. Then delete or rename 
the grpwise.ncf file to avoid future confusion. 


load volume:\system\agent.nlm @startup_ file 


+ Ifyou selected Yes under Load Agents in Protected Memory? (Agent Clustering 
Worksheet item 8), add the address space parameter to the agent load commands to 
specify the protected address space for each agent. Add a protection restart command for 
each address space name. 


load address space=addr_space_name 
volume:\system\agent.nlm @startup_ file 
protection restart name 


The result would look similar to the following example: 
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Properties of GWYOL_SERVER [x] 


P Address | Load Unload | Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Folé 
| Cluster Resource Load Script 


Script 


nss Jactivate=GWWVOL a 
mount GYVVOL VOLID=254 

cyshind add GVWW-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 

NUDP ADD GW-CLUSTER_GWVOL_SERVER 123.45.67.18 

add secondary ipaddress 123.45.67.18 

search add gwvolisystem 


SET AUTO RESTART AFTER ABEND = 2 

SET AUTO RESTART AFTER ABEND DELAY TIME = 0 
SET AUTO RESTART DOWN TIMEOUT = 60 

SET DEVELOPER OPTION = OFF 


LOAD address space=devpoa GYWWVOLASYSTEMIGWWPOA @DEVELOPM.POA 
protection restart devpoa 

LOAD address space=provoimta GWVOLASYSTEMIGWMTA @PROVO1.MTA 
protection restart provotmta 


al 5 


Timeout (secs) |600 


Page Options... | OK | Cancel [Can] Help | 


NOTE: The set commands are needed in the load script only when the agents are not running in 
protected memory. The address space parameters are needed in the load commands only when the 
agents are running in protected memory. 


4 Click Apply to save the load script. 


5 Ifnecessary, click OK to confirm that you must offline and then online the volume resource 
in order for the changes to take effect. 


6 Continue with “Modifying the Volume Resource Unload Script for the Agents” on page 48. 
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The volume resource unload script executes whenever the GroupWise volume goes offline. 
Programs should be unloaded in the reverse order of how they were loaded. This ensures that 
supporting programs are not unloaded before programs that rely on them in order to function 


properly. 


To set up the unload script: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume SERVER), 
click Unload to display the default volume resource unload script. 


2 Make the following changes to the default unload script: 


+ 


If you selected Yes under Load Agents in Protected Memory (Agent Clustering 
Worksheet item 8), add an unload address space command for each address space. Add 
an unload kill address space command to ensure that the address space is completely 
cleaned up. 


unload address space=addr_space_name 
unload kill address space=addr_space_name 


If your system seems to be trying to kill the address space before the GroupWise agents 
have been completely unloaded, resulting in the agents hanging in the unloading state, 
load the delay.nlm program and set a delay of several seconds before issuing the unload 
kill address space command to allow the GroupWise agents adequate time to unload 
completely. The length of the delay varies from system to system; ten seconds is a good 
starting place. 
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unload address space=addr_space_name 

load delay.nlm 

delay 10 

unload kill address space=addr_space_name 


+ Ifyou selected No under Load Agents in Protected Memory? (Agent Clustering 
Worksheet item 8), create an unload command parallel to each load command that you 
placed in the load script. 


unload volume: \directory\agent.nlm 


+ OnNetWare 5.1, if you selected SLP as a short name resolution method, add the cvsbind 
del command for the GroupWise volume to the unload script. 


cvsbind del cluster volume SERVER IP address 
+ Remove the trustmig command just like you did in the load script. 


The result would look similar to the following example: 


Properties of GWYOL_SERVER [x] 


P Address | Load | Ünioad || Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fold 


|| Custer Resource Unload Sri 


Script 


unload address space = devpoa a 
unload address space = provotmta 


del secondary ipaddress 123.45.67.18 

NUDP DEL GW-CLUSTER_GWVOL_SERVER 123.45.67.18 

cvshind del GW-CLUSTER_GWWOL_SERVER 123.45.67.18 # NetWare 5.1 only 
dismount GWVOL force 

nss forcedeactivate=GWVOL 


Kil » 
Timeout (secs) feoo 


Page Options... | OK Cancel | aoe] Help | 


3 Click Apply to save the unload script. 


4 If necessary, click OK to confirm that you must offline and then online the volume resource 
in order for the changes to take effect. 


5 Continue with “Setting the Failover Path and Policies for the Agents” on page 49. 


Setting the Failover Path and Policies for the Agents 
To modify the failover path and policies for a GroupWise volume resource: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume SERVER), 
click Nodes to display the default failover path for the GroupWise volume resource. 
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Properties of GWYOL_SERVER 


cee 


@ GW-CLUSTER1 
GW-CLUSTER2 
GW-CLUSTER3 

 GW-CLUSTER4 


2 Arrange the nodes in the cluster into the desired failover path for the domain or post office 
volume (under Agent Clustering Worksheet items 3 or 6). 


3 Click Apply to save the failover path. 
4 Click Policies to display the default start, failover, and failback policies. 


Properties of GWYOL_SERVER 


The default policy settings are often appropriate. By default, a volume resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the next node in its failover path 


+ Continues running at its failover location, even after its most preferred node is again 
available 


If you are considering changing these defaults, see the applicable section of Novell Cluster 
Services Overview and Installation for your version of NetWare: 


+ NetWare 6.x: “Set Start, Failover, and Failback Modes” 
+ NetWare 5.1: “Set Start, Failover, and Failback Modes” 
5 Click OK when you are finished editing the GroupWise volume resource properties. 


6 Continue with “Testing Your Clustered GroupWise System” on page 53. 
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Setting Up New Instances of the Agents without Installing the Agent Software 


There are two steps to setting up new instances of the agents without installing the agent software: 
+ “Creating New Startup Files” on page 51 
e “Modifying Existing Load and Unload Scripts” on page 51 


Creating New Startup Files 


Each MTA startup file is named after the domain it services, with a .mta extension. Each POA 
startup file is named after the post office it services, with a .poa extension. If the existing agent 
software is located in the vo/:\system directory of a GroupWise volume, the startup files will be 
there as well. If the existing agent software is located in multiple sys:\system directories, the 
startup files might be located there as well, or they might be in a directory on a GroupWise volume. 


To create a new startup file without installing the agent software: 


1 Make a copy of an existing startup file and name it after the domain or post office that will be 
serviced by the agent. 


2 Edit the setting of the /home startup switch to point to the location of the new domain directory 
or post office directory. Be careful to maintain the syntax of the original line. 


3 Scroll down through the startup file looking for other active (not commented out) startup 
switches, then modify them as needed for the new agent. 


For example, you might find that the /httpport switch is active and needs to be changed to a 
cluster-unique port number for the new agent. 


4 Save the new startup file. 


5 Continue with “Modifying Existing Load and Unload Scripts” on page 51. 


Modifying Existing Load and Unload Scripts 


The agent startup file names are part of the load commands found in GroupWise volume resource 
load scrips. 


If you created the new domain and/or post office on a new GroupWise volume, skip back to 
“Configuring the GroupWise Volume Resource to Load and Unload the Agents” on page 46 for 
instructions to create new load and unload scripts. 


If you created the new domain and/or post office on an existing GroupWise volume, most of the 
configuration of the volume resource has already been done. You just need to add new load and 
unload commands to the existing scripts. Continue with the steps below: 


To modify existing load and unload scripts: 
1 In ConsoleOne, browse to and select the Cluster object. 
If necessary, click View > Console View to display its contents. 


2 Right-click the Volume Resource object (volume SERVER), then click Properties > Load to 
display the volume resource load script for the GroupWise volume. 


3 Following the pattern of the existing load commands, add load commands for the new 
instances of the agents you are setting up. Use Ctrl+C to copy and Ctrl+V to paste lines in the 
load script page. 


The results would be similar to the following example: 


Setting Up a Domain and Post Office in a Novell Cluster 51 


52 


Properties of GWYOL_SERVER [x] 


P Address | Load Unload | Policies | Nodes | NDS Rights v | Other | Rights to Files and Fold 
| Cluster Resource Load Script 


Script 


nss Jactivate=GWVOL a 
mount GYVVOL VOLID=254 

cysbind add Gi¥V-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 

NUDP ADD GW-CLUSTER_GWVOL_SERVER 123.45.67.18 

add secondary ipaddress 123.45.67.18 

search add gwvolisystem 


SET AUTO RESTART AFTER ABEND = 2 

SET AUTO RESTART AFTER ABEND DELAY TIME = 0 
SET AUTO RESTART DOWN TIMEOUT = 60 

SET DEVELOPER OPTION = OFF 


LOAD address space=devpoa GYVVOLASYSTEMIGWWPOA @DEVELOPM.POA 
protection restart devpoa 

LOAD address space=provolmta GW/VOLASYSTEMIGWMTA @PROVO1.MTA 
protection restart provotmta 


al » 
Timeout (secs) [600 


Page Options... | OK | Cancel [Cen] Help | 


4 Click Apply to save the modified load script. 
5 Click Unload 


6 Add corresponding unload commands for the new instances of the agents. 


Properties of GWYOL_SERVER [x] 
P Address | Load Unload 
Script 
unload address space = devpoa a 


unload address space = provotmta 


del secondary ipaddress 123.45.67.18 

NUDP DEL GW-CLUSTER_GWVOL_SERVER 123.45.67.18 

cysbind del GW-CLUSTER_GWWOL_SERVER 123.45.67.18 # NetWare 5.1 only 
dismount GWVOL force 

nss forcedeactivate=GWVOL 


al » 
Timeout (secs) feoo 


Page Options... | OK | Cancel [Can] Help | 


7 Click Apply to save the modified unload script. 


You might want to review other properties of the Volume Resource object, such as the failover 
path on the Nodes page and the failover/failback/migration procedures on the Policies page, 
in light of the fact that an additional domain and/or post office now resides on the GroupWise 


volume. 
8 Change other Volume Resource properties as needed. 


9 Click OK to save the modified properties. 


10 In the Cluster State View, take the GroupWise volume offline and then bring it online again 
to test the new startup files and the modified load and unload scripts. If you need assistance 


with these tasks, see “Testing Your Clustered GroupWise System” on page 53. 
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Testing Your Clustered GroupWise System 


After you have configured the GroupWise volume resources, you can test the load and unload 
scripts by bringing the GroupWise volume online and taking it offline again. 


1 In ConsoleOne, select the Cluster object, then click View > Cluster State. 


Cluster State | Event Log | HTML Report| 


PP gw-cluster Epoch 1 Connected 


GW-CLUSTER1 GW-CLUSTER2 


Nodes Available (%) Resources Available ($) 
0 20 40 60 80 100 0 20 40 60 80 100 


Cluster Resource State Location #Lives | 
@ GWVOL_SERVER | Offline GW-CLUSTER1 2 | 
2 | 


@ ILVOL_SERVER Running | OW-CLUSTERI | 


The new GroupWise volume resource shows Offline in the State column. 
2 Click the new GroupWise volume resource, then click Online. 


The State column for the volume resource now displays Running. 


Cluster State | Event Log | HTML Report} 


p gw-cluster Epoch 1 Connected 
GW-CLUSTER1 GW-CLUSTER2 
| Nodes Available (%) Resources Available (%) 
0 20 40 60 80 100 0 20 40 60 80 100 
Cluster Resource State Location #Lives | 
@ GWVOL_SERVER | Running GW-CLUSTER1 2 | 
@ ILVOL_SERVER Running GW-CLUSTER1 2 


3 Observe the server console where the MTA and/or POA are loading to see that they start and 
run correctly. 


If you are using protected memory, you can use the protection command at the server console 
prompt to list all the address spaces on the node and what NLM programs are running in each 
one. 


4 Click the new GroupWise volume resource, then click Offline. 
The State column for the volume resource returns to Offline. 


5 Observe the server console where the MTA and/or POA are unloading to see that they shut 
down correctly. 


If you are using protected memory, you can use the protection command again to make sure 
that the address spaces used by the GroupWise agents are no longer present. 


6 Repeat Step 2 whenever you are ready to bring the new GroupWise volume resource online 
permanently. 
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On NetWare 6.x, these actions can also be performed from your Web browser. See “Using 
NetWare Remote Manager on NetWare 6.x” on page 55. 


7 Continue with “Managing Your Clustered GroupWise System” on page 54. 


Managing Your Clustered GroupWise System 
After you have set up a basic clustered GroupWise system, you should consider some long-term 
management issues. 
+ “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 54 
+ “Using NetWare Remote Manager on NetWare 6.x” on page 55 
+ “Knowing What to Expect in MTA and POA Failover Situations” on page 58 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After setting up your clustered GroupWise system, while the cluster-specific information is fresh 
in your mind, you should record that cluster-specific information as part of the GroupWise objects 
in ConsoleOne so that you can easily refer to it later. Be sure to keep the information recorded in 
the GroupWise objects up to date if the configuration of your system changes. 


+ “Recording Cluster-Specific Information for a Domain and Its MTA” on page 54 
+ “Recording Cluster-Specific Information for a Post Office and Its POA” on page 54 


+ “Recording Cluster-Specific Information for a Software Distribution Directory” on page 55 


Recording Cluster-Specific Information for a Domain and Its MTA 


To permanently record important cluster-specific information for the domain: 
41 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 In the Description field of the domain Identification page, provide a cluster-specific 
description of the domain, including the secondary IP address of its cluster-enabled volume 
and the cluster-unique port numbers used by its MTA. 


Click OK to save the domain description. 
Select the Domain object to display its contents. 


Right-click the MTA object, then click Properties. 


aoa bh Ww 


In the Description field of the MTA Identification page, record the secondary IP address of 
the cluster-enabled domain volume and the cluster-unique port numbers used by the MTA. 


This information will appear on the MTA console, no matter which node in the cluster it is 
currently running on. 


7 Click OK to save the MTA description. 


8 Continue with “Recording Cluster-Specific Information for a Post Office and Its POA” on 
page 54. 


Recording Cluster-Specific Information for a Post Office and Its POA 
To permanently record important cluster-specific information for a post office: 


1 In ConsoleOne, browse to and right-click the Post Office object, then click Properties. 
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2 In the Description field of the post office Identification page, provide a cluster-specific 
description of the post office, including the secondary IP address of its cluster-enabled volume 
and the cluster-unique port numbers used by its POA. 


Click OK to save the post office description. 
Select the Post Office object to display its contents. 
Right-click the POA object, then click Properties. 


oa bh Ww 


In the Description field of the POA Identification page, record the secondary IP address of the 
cluster-enabled post office volume and the cluster-unique port numbers used by the POA. 


This information will appear on the POA console, no matter which node in the cluster it is 
currently running on. 


7 Click OK to save the POA description. 


8 Ifnecessary, continue with “Recording Cluster-Specific Information for a Software 
Distribution Directory” on page 55. 


or 


Continue with “Knowing What to Expect in MTA and POA Failover Situations” on page 58. 


Recording Cluster-Specific Information for a Software Distribution Directory 


To permanently record important cluster-specific information about a software distribution 
directory located on a cluster-enabled volume: 


1 In ConsoleOne, click Tools > System Operations > Software Directory Management. 
2 Select the software distribution directory, then click Edit. 


3 In the description field, record the secondary IP address of the cluster-enabled volume where 
the software distribution directory resides. 


4 Click OK, then click Close to save the software distribution directory description. 


5 Continue with “Knowing What to Expect in MTA and POA Failover Situations” on page 58. 


Using NetWare Remote Manager on NetWare 6.x 


On NetWare 6.x, you can use NetWare Remote Manager to manage many aspects of your 

Group Wise cluster from your Web browser. For instructions on setting up and accessing this useful 
network administration utility, see the NetWare 6.x NetWare Remote Manager Administration 
Guide at the Novell Documentation Web site (http://www.novell.com/documentation/index.html). 
Cluster management features are automatically added to NetWare Remote Manager when you 
install Novell Cluster Services. 


After you have accessed NetWare Remote Manager, you might find that many Group Wise cluster 
management tasks are easier to perform with NetWare Remote Manager than with ConsoleOne. 
The following sections help you configure and manage the cluster using NetWare Remote 
Manager: 


+ “Configuring Your Group Wise Cluster” on page 56 
+ “Managing Your GroupWise Cluster” on page 57 
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Configuring Your GroupWise Cluster 


On the main NetWare Remote Manager page: 


1 In the left frame, scroll down to the Clustering section, then click Cluster Config. 


NetWare Remote Manager 


NetWare 6 Server Version 5.60, September 13, 2001 
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Protocol Information = 


Jove Anlestion © | gustan chsorcomig 


Information 

Manage Hardware gw-cluster Cluster Config 
Processors P 
Disk / LAN Adapters gw-cluster 
oleae Node Name Number IP Address 
Other Resources 

Manage eDirectory GW.CLUSTER1 0 123.456.78.91 
Access Tree Walker Vc sent 
View eDirectory GW-CLUSTER? | 123.456.78.92 
Partitions S 
NDS iMonitor © Resources —— 

U ee 4 1. Master _IP_Address Resource 
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New Cluster Resource 


The Cluster Configuration page displays the cluster name, the nodes in the cluster, and the 
resources in the cluster. It also enables you to create new GroupWise Volume Resource objects 
(termed Cluster Volumes in the NetWare Remote Manager interface). 


2 Click the cluster name to display the Cluster object properties: 


Cluster Configuration Fields: gw-cluster 
Revision 261 

IP Address 123.456.78.99 
Port Number 7023 

Quorum 

Membership 2 

Timeout 60 

Protocol 

Tolerance 8 

Heartbeat 1 

Master Watchdog 1 

Slave Watchdog 8 

Max Retransmit 30 

GIPC Stream 

Resource Priorities 

Email Reporting 


Click a linked item to edit the Cluster object properties. Click your browser’s Back button to 
return to the Cluster Configuration page. 


3 On the Cluster Configuration page, click a server to display the Server object properties: 


IP Address 123.456.78.99 
Node Number 0 
Back Delete 


Click a linked item to edit the Server object properties. Click Back or Delete to perform the 
specified action. 
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4 On the Cluster Configuration page, click a GroupWise volume to display the Volume 
Resource object properties: 


IP Address 123.456.78.90 


Loading Unloading 

Script Timeout Script Timeout 
600 600 

Policies 908 No Start Auto FailOver Manual FailBack Disabled Master 
Quorum 

Nodes GW-CLUSTER1, GW-CLUSTER2 , GW-CLUSTER3 , GW-CLUSTER4 

Back Delete 


Click a linked item to edit Volume Resource object properties. Click Back or Delete to 
perform the specified action. 


5 On the Cluster Configuration page, click New Cluster Volume to create a new GroupWise 
Volume Resource object, then follow the instructions to provide the information needed to 
create the new Cluster Volume object. 
Managing Your GroupWise Cluster 
On the main NetWare Remote Manager page: 


1 In the left frame, scroll down to the Clustering section, then click Cluster Management. 


ell NetWare 6 Server Version 5.60, September 13, 2001 
NetWare Remote Manager hentication edmi) 
i: p oA Novell. 


Other Resources 
Manage eDirectory 


Access Tree Walker 
View eDirector 5 
Partitions 5 Begin Refresh | Page Refresh Rate fio seconds | 
NDS iMonitor 
DS Trace 
Use Server Groups Epoch 1 
Build Group 
Load Group File Nodes 
Access Other Servers 
Managed Server List l| E A 
pano pieraecoas GW-CLUSTER1 GW-CLUSTER2 GW-CLUSTERS 
Clustering 
Health Monitors Master IP_Address_ Resource Running GW-CLUSTER1 1 10-30-2001 5:32:03 pm 
NDPS Broker Health GWVOL_ SERVER Running GW-CLUSTER1 4 11-27-2001 1:53:39 pm 
NetWare Usage ILVOL_SERVER Running GW-CLUSTER1 1 10-30-2001 5:32:03 pm 
Usage Information 
Configuration 
g - Event Log a 


The Cluster Status page displays the nodes and volume resources in the cluster. The master 
node in the cluster is marked with a yellow ball. Status information is listed for each volume 
resource. You can set the refresh rate for the status information at the top of the Cluster Status 


page. 


2 Select a page refresh rate, then click Begin Refresh so that the page automatically refreshes at 
the selected rate. 


3 Click a cluster resource to bring it online, take it offline, or migrate it to another node. 
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Resource Action for GWVOL_SERVER 
State Running GW-CLUSTER1 


GW-CLUSTER2 = 


Offline | {GW-CLUSTER3 
Migrate 


GW-CLUSTER4 ¥] 
To take the currently running volume resource offline, click Offline. To migrate the volume 
resource, select a node from the drop-down list, then click Migrate. 
4 On the Cluster Resource page, click Event Log to view a list of cluster events. 


The event log can help you resolve problems with cluster functioning. 


Knowing What to Expect in MTA and POA Failover Situations 


What’s Next 
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In a failover situation, the agents might need to perform some database repair as they start on the 
new node. The time required depends on the size of the databases involved. 


Typically, the POA returns to full functionality faster than the MTA. This benefits Group Wise 
client users who can reconnect to their mailboxes very quickly and probably will not notice if 
messages to users in other post offices are not delivered immediately. The only time a user would 
need to restart the Group Wise client would be if he or she was actually in the process of sending a 
message when the POA went down. Notify can continue running even if the connection to the POA 
becomes unavailable and then it reconnects automatically when the POA is again available. 


The MTA typically takes some time reestablishing the links to its post offices, other domains, and 
gateways, but this situation usually resolves itself in a few minutes without administrator 
intervention. If it does not, you can manually restart the MTA to speed up the process. 


In comparison to failover, migration typically takes longer because the agents methodically 
terminate their threads and close their databases as part of their normal shutdown procedure. 
However, as a result, no database repair is required when the agents start up again in their new 
location. 


Continue with “What’s Next” on page 58. 


Now that you have at least one GroupWise domain and post office up and running in a clustering 
environment, you are ready to proceed with the rest of your GroupWise system setup by: 


+ Adding users to post offices. See “Users” in the GroupWise 6.5 Administration Guide. 


¢ Setting up the Group Wise client software and helping users to get started using it. See “Client” 
in the GroupWise 6.5 Administration Guide. Also see the GroupWise 6.5 Windows Client User 
Guide. 


+ Connecting your clustered GroupWise system to the Internet. See Chapter 4, “Implementing 
the Internet Agent in a Novell Cluster,” on page 63. 


¢ Providing access to users’ GroupWise mailboxes from their Web browsers. See Chapter 5, 
“Implementing WebAccess in a Novell Cluster,” on page 83. 


+ Connecting your clustered Group Wise system to other e-mail systems through GroupWise 
gateways. See Chapter 6, “Implementing GroupWise Gateways in a Novell Cluster,” on 
page 103. 
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+ Monitoring the status of your clustered GroupWise system from your Web browser. See 
Chapter 7, “Monitoring a GroupWise System in a Novell Cluster,” on page 105. 


+ Backing up your clustered GroupWise system. See Chapter 8, “Backing Up a GroupWise 
System in a Novell Cluster with the GroupWise TSA,” on page 107. 


Clustering Quick Checklists 


+ “GroupWise System Quick Checklist” on page 59 
+ “Domain Quick Checklist” on page 60 
+ “Post Office Quick Checklist” on page 61 


GroupWise System Quick Checklist 

Q) Plan your new clustered GroupWise system. 

See Chapter 2, “Planning GroupWise in a Novell Cluster,” on page 17. 

Q) Cluster-enable the volumes where GroupWise domains and post offices will reside. 
See “Cluster-Enabling Shared Volumes for Use with GroupWise” on page 37. 

Q) Make sure that short name resolution works throughout your network. 

See “Configuring Short Name Resolution” on page 38. 

Q) Create the primary domain and initial post office in your new clustered Group Wise system. 
See “Setting Up a New GroupWise System in a Cluster” on page 40. 

Q) Set up the agents for the primary domain and the initial post office. 

See “Installing and Configuring the MTA and the POA in a Cluster” on page 44. 


Q Modify the volume resource load script(s): 

+ Remove the trustmig command 

+ Add the cvsbind add command (NetWare 5.1 only; optional) 
+ Add the search add command (optional) 


¢ Ifyou will not run the agents in protected memory, add the set auto restart commands and 
the set developer option = off command 


+ Add the agent load command(s) 


+ If you will run the agents in protected memory, add the address space parameter to the 
load command(s) and add a corresponding protection restart command for each address 
space 


See “Modifying the Volume Resource Load Script for the Agents” on page 46. 
QO) Modify the volume resource unload script(s): 
+ Add the agent or address space unload command(s) 


+ Add the cvsbind del command if you used the cvsbind add command in the load script 
(NetWare 5.1 only; optional) 


+ Remove the trustmig command 


See “Modifying the Volume Resource Unload Script for the Agents” on page 48. 
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Set up the volume failover path(s) and policies. 

See “Setting the Failover Path and Policies for the Agents” on page 49. 
Test your new clustered GroupWise system. 

See “Testing Your Clustered GroupWise System” on page 53. 


Record cluster-specific information in the properties pages of the GroupWise objects that the 
information pertains to. 


See “Managing Your Clustered GroupWise System” on page 54. 


Domain Quick Checklist 
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m) 


m) 


Plan your new clustered domain. 

See “Planning a New Clustered Domain” on page 20. 

Cluster-enable the volume where the domain will reside. 

See “Cluster-Enabling Shared Volumes for Use with GroupWise” on page 37. 


Make sure that short name resolution for the new domain volume works throughout your 
network. 


See “Configuring Short Name Resolution” on page 38. 
Create the new domain. 
See “Creating a New Secondary Domain in a Cluster” on page 42. 
Set up the MTA for the new domain. 
See “Installing and Configuring the MTA and the POA in a Cluster” on page 44. 
Modify the domain volume resource load script: 
+ Remove the trustmig command 
+ Add the cvsbind add command (NetWare 5.1 only; optional) 
+ Add the search add command (optional) 


+ Ifyou will not run the MTA in protected memory, add the set auto restart commands and 
the set developer option = off command 


+ Add the MTA load command 


+ Ifyou will run the MTA in protected memory, add the address space parameter to the mta 
load command and add a corresponding protection restart command for the address space 


See “Modifying the Volume Resource Load Script for the Agents” on page 46. 
Modify the domain volume resource unload script: 
+ Add the MTA or address space unload command 


+ Add the cvsbind del command if you used the cvsbind add command in the load script 
(NetWare 5.1 only; optional) 


+ Remove the trustmig command 
See “Modifying the Volume Resource Unload Script for the Agents” on page 48. 
Set up the domain volume failover path and policies. 


See “Setting the Failover Path and Policies for the Agents” on page 49. 
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m) 


m) 


Test your new clustered domain. 
See “Testing Your Clustered GroupWise System” on page 53. 


Record cluster-specific information in the properties pages of the GroupWise objects that the 
information pertains to. 


See “Managing Your Clustered GroupWise System” on page 54. 


Post Office Quick Checklist 


m) 


m) 


m) 


Plan your new clustered post office. 

See “Planning a New Clustered Post Office” on page 21. 

Cluster-enable the volume where the post office will reside. 

See “Cluster-Enabling Shared Volumes for Use with GroupWise” on page 37. 


Make sure that short name resolution for the new post office volume works throughout your 
network. 


See “Configuring Short Name Resolution” on page 38. 

Create the new post office. 

See “Creating a New Post Office in a Cluster” on page 43. 

Set up the POA for the new post office. 

See “Installing and Configuring the MTA and the POA in a Cluster” on page 44. 


Add the /ip startup switch to the POA startup file in order to provide the secondary IP address 
of the post office volume. If you are running the POA in protected memory, add the /user and 
/password startup switches so the POA can access the volume. 


See “Editing Clustered Agent Startup Files” on page 45. 

Modify the post office volume resource load script: 
+ Remove the trustmig command 
¢ Add the cvsbind add command (NetWare 5.1 only; optional) 
+ Add the search add command (optional) 


+ Ifyou will not run the POA in protected memory, add the set auto restart commands and 
the set developer option = off command 


+ Add the POA load command 


+ Ifyou will run the POA in protected memory, add the address space parameter to the poa 
load command and add a corresponding protection restart command for the address space 


See “Modifying the Volume Resource Load Script for the Agents” on page 46. 
Modify the post office volume resource unload script: 
+ Add the POA or address space unload command 


+ Add the cvsbind del command if you used the cvsbind add command in the load script 
(NetWare 5.1 only; optional) 


+ Remove the trustmig command 


See “Modifying the Volume Resource Unload Script for the Agents” on page 48. 
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Q) Set up the post office volume failover path and policies. 
See “Setting the Failover Path and Policies for the Agents” on page 49. 
Q Test your new clustered post office. 


See “Testing Your Clustered GroupWise System” on page 53. 


Q) Record cluster-specific information in the properties pages of the GroupWise objects that the 
information pertains to. 


See “Managing Your Clustered GroupWise System” on page 54. 
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Implementing the Internet Agent in a Novell 
Cluster 


You should already have set up at least a basic GroupWise® system, as described in Chapter 2, 
“Planning GroupWise in a Novell Cluster,” on page 17 and Chapter 3, “Setting Up a Domain and 
Post Office in a Novell Cluster,” on page 37. As part of this process, the “System Clustering 
Worksheet” on page 32 and the “IP Address Worksheet” on page 34 were filled out. If you do not 
have access to the filled-out worksheets, print the worksheets now and fill in the clustering and 
network address information as it currently exists on your system. You will need this information 
as you implement the Internet Agent in a cluster. 


+ “Planning the Internet Agent in a Cluster” on page 63 

¢ “Setting Up the Internet Agent in a Cluster” on page 67 
+ “Managing the Internet Agent in a Cluster” on page 76 
+ “Internet Agent Clustering Worksheet” on page 78 

+ “Internet Agent Quick Checklist” on page 80 


Planning the Internet Agent in a Cluster 


A main system configuration difference between a GroupWise system in a clustering environment 
and a Group Wise system in a regular environment is that you need to create a separate domain to 
house each GroupWise gateway, including the Internet Agent. 


The “Internet Agent Clustering Worksheet” on page 78 lists all the information you will need as 
you set up the Internet Agent in a clustering environment. You should print the worksheet and fill 
it out as you complete the tasks listed below: 


+ “Planning a Domain for the Internet Agent” on page 64 
+ “Deciding Whether to Cluster-Enable the Internet Agent Volume” on page 64 
+ “Determining an Appropriate Failover Path for the Internet Agent Volume” on page 64 


+ “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the Internet Agent 
and Its MTA” on page 65 


+ “Preparing Your Firewall for the Internet Agent” on page 65 

+ “Deciding Where to Install the Internet Agent and Its MTA” on page 66 

+ “Deciding Whether to Run the Internet Agent and Its MTA in Protected Memory” on page 66 
+ “Planning the MTA Installation” on page 66 


+ “Planning the Internet Agent Installation” on page 66 
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Planning a Domain for the Internet Agent 


The considerations involved in planning a domain for the Internet Agent are much the same as 
planning any other domain. In preparation, review “Planning a New Domain”, then print and fill 
out the “Domain Worksheet” in “Domains” in the GroupWise 6.5 Administration Guide. 


Keep in mind the following cluster-specific details: 


+ When you specify the location for the domain directory on the Domain Worksheet, include 
the shared volume where you want the domain directory to reside. 


+ Do not concern yourself with the GroupWise agent information on the Domain Worksheet. 
You can stop with item 10. You will plan the MTA installation later. 


When you have completed the Domain Worksheet, transfer the key information from the Domain 
Worksheet to the Internet Agent Clustering Worksheet. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 1: Shared Volume for Internet Agent, transfer the domain location to the Internet Agent 
Clustering Worksheet. 


Under Item 2: Internet Agent Domain Name, transfer the domain name and database directory to the 
Internet Agent Clustering Worksheet. 


Deciding Whether to Cluster-Enable the Internet Agent Volume 


You should plan to cluster-enable the shared volume where the Internet Agent domain will reside. 
For a review of the benefits of cluster-enabling volumes, see “Deciding Whether to Cluster-Enable 
the Shared Volumes Used by GroupWise” on page 21, which describes the issues in the context of 
planning MTA and POA installations. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 1: Shared Volume for Internet Agent, mark Yes under Cluster Enabled?. 


Cluster-enabling relies on successful short name resolution throughout your system. Review 
“Ensuring Successful Name Resolution for GroupWise Volumes” on page 23, which describes the 
issues in the context of planning MTA and POA installations. 


Determining an Appropriate Failover Path for the Internet Agent Volume 
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As with the MTA and the POA, you need to decide which nodes in the cluster would be appropriate 
locations for the Internet Agent volume to fail over to. For a review of failover paths, see 
“Determining Appropriate Failover Paths for the Agents” on page 27, which describes the issues 
in the context of planning MTA and POA installations. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 3: Internet Agent Failover Path, list the nodes that you want to have in the Internet Agent 
volume failover path. 
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Planning a Secondary IP Address and Cluster-Unique Port Numbers for the 
Internet Agent and Its MTA 


As with the MTA and the POA, the Internet Agent needs a secondary IP address and cluster-unique 
port numbers. As part of planning to install the MTA and POA, you should already have 
determined the secondary IP address and cluster-unique port numbers for the Internet Agent and 
its MTA as you filled out the “IP Address Worksheet” on page 34. If you do not have a filled-out 
copy of this worksheet for your system, print it now and fill in current system information. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 5: MTA Network Information, transfer the MTA secondary IP address and cluster-unique 
port numbers from the Internet Agent section of the IP Address Worksheet to the Internet Agent 
Clustering Worksheet. 


Under Item 1: Shared Volume for Internet Agent, copy the MTA secondary IP address under Cluster 
Volume IP Address as well, because they are the same. 


Under Item 7: Internet Agent Network Information, transfer the Internet Agent secondary IP address 
(the same as for its MTA) and the cluster-unique Internet Agent port number from the Internet Agent 
section of the IP Address Worksheet to the Internet Agent Clustering Worksheet. 


Preparing Your Firewall for the Internet Agent 


The Internet Agent will receive incoming messages on the secondary IP address of the Internet 
Agent domain volume. Your firewall configuration must be modified to allow inbound TCP/IP 
traffic from the Internet to the Internet Agent secondary IP address on the following standard ports: 


Protocol Standard Port 
IMAP4 143 

LDAP 389 

POP3 110 

SMTP 25 


By default, the Internet Agent will send outgoing messages on the primary IP address of the server 
where it is running. If you decide to use this default configuration, your firewall must be 
configured to allow outbound TCP/IP traffic from all nodes in the Internet Agent volume failover 
path. 


If the Internet Agent has a large number of nodes on its failover path, you could configure the 
Internet Agent to send outgoing messages to a relay host, which would then send them out through 
the firewall using its own IP address rather than the address of the particular node where the 
Internet Agent was running. This reduces the amount of modification to your firewall required to 
set up the Internet Agent. However, if the relay host goes down, outgoing messages would be 
delayed. 


As another alternative, you can configure the Internet Agent to use its secondary IP address for 
sending as well as receiving messages. Setup instructions for this configuration are provided in 
“Forcing Use of the Internet Agent Secondary IP Address” on page 75, which you can complete 
after installing the Internet Agent. 


In preparation for installing the Internet Agent, configure your firewall as needed to handle the 
Internet Agent’s use of primary and secondary IP addresses when sending and receiving messages. 
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Deciding Where to Install the Internet Agent and Its MTA 


As with the MTA and the POA, you can choose to install the Internet Agent and its MTA to the 
sys:\system directory of each node or to a vol:\system directory on the Internet Agent volume. For 
a discussion of these alternatives, see “Deciding Where to Install the Agent Software” on page 28, 
which describes the issues in the context of planning MTA and POA installations. If you only have 
one Internet Agent for your Group Wise system with several servers in its failover path, it is an easy 
choice: Install it once to a vol:\system directory on the Internet Agent volume. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 4: MTA Installation Location and Item 6: Internet Agent Installation Location, mark whether 
you will install the Internet Agent and its MTA to a vol:\system directory on the Internet Agent volume 
or to sys:\system on each node in the cluster. If necessary, specify where the MTA startup file and the 
Internet Agent configuration file will be stored. 


Deciding Whether to Run the Internet Agent and Its MTA in Protected Memory 


As with the MTA and the POA, you can choose whether to run the Internet Agent in protected 
memory. For a review of the benefits of protected memory, see “Deciding Whether to Run the 
Agents in Protected Memory” on page 30, which describes the issues in the context of planning 
MTA and POA installations. 


You might think that protected memory would not be necessary if you have only one Internet 
Agent for your Group Wise system because it could never fail over to anode where another Internet 
Agent was running. However, because the Internet Agent in a cluster is installed into its own 
domain with its own MTA, this MTA could fail over to a node where another MTA was already 
running. Therefore, it is safest to load the MTA into protected memory. Loading the Internet Agent 
into protected memory is also recommended. Load each agent into its own memory space and 
mark each memory space as restartable. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 8: Load Internet Agent and Its MTA in Protected Memory?, mark whether you need to run 


the Internet Agent and its MTA in protected memory. If you do, provide a protected memory address 
space name for each agent. 


Planning the MTA Installation 


Follow the instructions in “Planning the NetWare Agent Installation” on page 30, then return to 
this point. After you follow the instructions, you will have a filled-out NetWare Agent Worksheet 
to use when you install the MTA. 


IMPORTANT: Do not install the NetWare MTA until you are instructed to do so in “Setting Up the Internet 
Agent in a Cluster” on page 67. 


Planning the Internet Agent Installation 
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Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Internet Agent are the same in a clustering environment as for 
any other environment. Review the installation instructions in “Installing the Internet Agent 
Software on NetWare or Windows” in “Installing the GroupWise Internet Agent” in the 
GroupWise 6.5 Installation Guide. You might want to print this section and write down the types 
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of planning information you have provided on worksheets in other sections. You will need this 
information as you install the Internet Agent in your cluster. 


IMPORTANT: Do not install the Internet Agent software until you are instructed to do so in “Setting Up the 
Internet Agent in a Cluster” on page 67. 


Setting Up the Internet Agent in a Cluster 


You should already have reviewed “Planning the Internet Agent in a Cluster” on page 63 and filled 
out the “Internet Agent Clustering Worksheet” on page 78. You are now ready to complete the 
following tasks to set up the Internet Agent in a clustering environment: 


+ 


+ 


+ 


+ 


+ 


+ 


“Cluster-Enabling a Shared Volume for Use with the WebAccess Agent” on page 88 
“Creating a Domain for the Internet Agent” on page 68 

“Installing the MTA for the Internet Agent Domain” on page 68 

“Installing and Configuring the Internet Agent in a Cluster” on page 68 

“Testing the Clustered Internet Agent” on page 75 

“Managing the Internet Agent in a Cluster” on page 76 


Cluster-Enabling a Shared Volume for Use with the Internet Agent 


To cluster-enable the Internet Agent shared volume: 


1 


Complete the steps in the applicable section of Novell Cluster Services Overview and 
Installation for your version of NetWare: 


+ NetWare 6.x: “Cluster Enable Pools and Volumes” 
+ NetWare 5.1: “Cluster-Enable Volumes ” 


The Internet Agent Clustering Worksheet provides the volume to cluster-enable, the cluster- 
enabled volume IP address, and the failover path for the Internet Agent volume. 


For a review of the new Novell® eDirectory™ objects that are created when you cluster-enable 
a shared volume, see “Deciding Whether to Cluster-Enable the Shared Volumes Used by 
GroupWise” on page 21. 


Ifyou have installed the latest version of ConsoleOne® and the Novell Cluster Services snap- 
in, as described in “Updating to the Latest ConsoleOne Snap-In” on page 18, you will be able 
to rename the cluster-related objects in case your DNS name server cannot resolve object 
names that include the underscore (_) character. 


To ensure successful short name resolution, add entries for the Internet Agent virtual server to 
support your preferred methods of short name resolution, as described in “Configuring Short 
Name Resolution” on page 38. 


To ensure that the Internet Agent has incoming and outgoing access to the Internet, make sure 
your firewall is properly configured, as described in “Preparing Your Firewall for the Internet 
Agent” on page 65. 


4 Continue with “Creating a Domain for the Internet Agent” on page 68. 
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Creating a Domain for the Internet Agent 


The Internet Agent domain will be a secondary domain. To create it, follow the instructions in 
“Creating a New Secondary Domain in a Cluster” on page 42, taking your information from the 
Internet Agent Clustering Worksheet, rather than the System Clustering Worksheet, then return to 
this point. 


Do not create any post offices in the Internet Agent domain. 


Continue with “Installing the MTA for the Internet Agent Domain” on page 68. 


Installing the MTA for the Internet Agent Domain 


The MTA for the Internet Agent domain can be installed just like any other MTA in your clustered 
Group Wise system. Follow the instructions in “Installing the Agent Software in a Cluster” on 
page 45, then return to this point. 


You do not need to edit the MTA startup file. You do not need to modify the Volume Resource 
properties until after you have installed the Internet Agent. 


Continue with “Installing and Configuring the Internet Agent in a Cluster” on page 68. 


Installing and Configuring the Internet Agent in a Cluster 


After you have created a domain for the Internet Agent and installed the MTA for that domain, you 
are ready to install and configure the Internet Agent. 


+ “Installing the Internet Agent Software in a Cluster” on page 68 


+ “Configuring the Internet Agent Volume Resource to Load and Unload the Internet Agent and 
Its MTA” on page 69 


+ “Enabling Internet Addressing for Your Clustered GroupWise System” on page 74 
+ “Verifying GWIA Object Properties” on page 74 


Installing the Internet Agent Software in a Cluster 


68 


1 Map a drive to the Internet Agent volume (Internet Agent Clustering Worksheet item 1). 


The Internet Agent volume name will be cluster_volume. For assistance with mapping a drive 
to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 38. 


2 If you selected vol:\system on Internet Agent Volume as the Internet Agent installation 
location (Internet Agent Clustering Worksheet item 6), create the vol:\system directory on the 
Internet Agent volume accessed in Step 1. 


or 


If you selected sys:\system on Each Node, decide which node you will install the Internet 
Agent to first, then map a drive to sys:\system on that node. 


3 Start the Internet Agent Installation program and install the NetWare® Internet Agent, 
following the steps provided in “Installing the Internet Agent Software on NetWare or 
Windows” in “Installing the GroupWise Internet Agent” in the GroupWise 6.5 Installation 
Guide. Keep in mind the following cluster-specific details: 


+ Use the notes you made during “Planning the Internet Agent Installation” on page 66 to 
fill in the fields during the Internet Agent installation process. 
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+ Inthe Installation Path dialog box, be sure to browse through the drive you mapped to the 
location you chose in Step 2 above. Deselect Update AUTOEXEC File and select 
Configure GroupWise Agents for Clustering. 


+ Inthe GroupWise Domain dialog box, be sure to browse through the drive you mapped 
in Step 1 to the domain directory (Internet Agent Clustering Worksheet item 2). 


¢ The Internet Agent Installation program creates the gwia.ncf file, which includes the load 
command for the Internet Agent. You will use this information later when you create the 
load script for the Volume Resource object. 


4 If you need to install the Internet Agent to sys:\system to each node in the cluster: 
4a Repeat Step 3, mapping new drives as needed. 


4b If you selected Yes for Consolidate Multiple Configuration Files on Internet Agent 
Volume? (under Internet Agent Clustering Worksheet item 6), copy the gwia.cfg file to 
the planned location, then delete it from the sys:\system directories to avoid future 
confusion. 


5 Make sure you have completed all the tasks described in “Installing the GroupWise Internet 
Agent” in the GroupWise 6.5 Installation Guide. 


The Internet Agent starts automatically immediately after Installation. 
6 Stop each Internet Agent you have installed before configuring it for clustering. 


7 Continue with “Configuring the Internet Agent Volume Resource to Load and Unload the 
Internet Agent and Its MTA” on page 69. 


Configuring the Internet Agent Volume Resource to Load and Unload the Internet Agent and Its MTA 


The properties of the Volume Resource object define how the Internet Agent volume functions 
within the cluster, how NLM programs are loaded and unloaded, and how failover and failback 
situations are handled. Complete the following tasks for the Internet Agent volume: 


+ “Modifying the Volume Resource Load Script for the Internet Agent” on page 69 
+ “Modifying the Volume Resource Unload Script for the Internet Agent” on page 71 
¢ “Setting the Failover Path and Policies for the Internet Agent” on page 72 


Modifying the Volume Resource Load Script for the Internet Agent 
The volume resource load script executes whenever the Internet Agent volume comes online. 


To set up the load script: 
1 In ConsoleOne, browse to and select the Cluster object. 
If necessary, click View > Console View to display its contents. 


2 Right-click the Volume Resource object (volume SERVER), then click Properties > Load to 
display the default volume resource load script for the Internet Agent volume. 


The next step assumes that this is the first time you have edited this load script. If other 
GroupWise agents are already running from this volume, some of the modifications will 
already have been made. 


3 Make the following changes to the default load script: 


+ Remove the trustmig command. It is not necessary to migrate trustees for the Internet 
Agent volume. Removing this line helps the load script to execute faster. 
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+ On NetWare 5.1, if you are using SLP as a short name resolution method, as described in 
“Configuring Short Name Resolution” on page 38, add the cvsbind add command for the 
Internet Agent volume to the load script. 


evsbind add cluster volume SERVER IP address 


+ Ifyou selected vol:\system on Internet Agent volume as the installation location (Internet 
Agent Clustering Worksheet items 4 and 6), add a search add command to add the new 
vol:\system directory to the server search path. 


search add volume:\system 


+ Ifyou selected sys:\system on each node as the installation location (Internet Agent 
Clustering Worksheet items 4 and 6) but you are storing the MTA startup file and the 
Internet Agent configuration file on the Internet Agent volume, add that location to the 
server search path. 


+ Ifyou selected No under Load Internet Agent and Its MTA in Protected Memory? 
(Internet Agent Clustering Worksheet item 8), add the following abend recovery options: 


set auto restart after abend = 2 

set auto restart after abend delay time = 0 
set auto restart down timeout = 60 

set developer option = off 


These settings provide the best possible handling of GroupWise databases in the event 
that an abend should occur within the cluster. 


+ Transfer the MTA load command from the grpwise.ncf file located in the vol:\system 
directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text into the load 
script page. Then delete or rename the grpwise.ncf file to avoid future confusion. 


load volume:\system\gwmta.nlm @domain.mta 
+ Adda delay so that the MTA is fully loaded before the Internet Agent starts to load: 


load delay.nlm 
delay 10 


The length of the delay varies from system to system; ten seconds is a good starting place. 


¢ Transfer the Internet Agent load command from the gwia.ncf file located in the 
vol:\system directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text 
into the load script page. Then delete or rename the gwia.ncf file to avoid future 
confusion. 


load volume:\system\gwia.nlm @gwia.cfg 


+ Ifyou selected Yes under Load Internet Agent and Its MTA in Protected Memory? 
(Internet Agent Clustering Worksheet item 8), add the address space parameter to the load 
commands to specify the protected address space where the Internet Agent and its MTA 
will run. Add a protection restart command for the address space name. 


load address space=addr_space_ name 
volume: \system\gwmta.nlm @domain.mta 

load address space=addr_space_ name 
volume: \system\gwia.nlm @gwia.cfg 

protection restart addr space _ name 


The result would look similar to the following example: 
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Properties of GWYOL_SERVER [x] 


P Address | Load | Uniosa | Policies | Nodes | NDS Rights | Other | Rights to Files and Fole 
(Cians Coad sca 


Script 


nss /activate=GWVOL = 
mount GYVVOL VOLID=254 

cysbind add GYV-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 

NUDP ADD GWW-CLUSTER_GWYVOL_SERVER 123.45.67.18 

add secondary ipaddress 123.45.67.18 

search add gwvolisystem 


SET AUTO RESTART AFTER ABEND = 2 

SET AUTO RESTART AFTER ABEND DELAY TIME = 0 
SET AUTO RESTART DOWN TIMEOUT = 60 

SET DEVELOPER OPTION = OFF 


LOAD address space=gwia GWVOLASYSTEMIGWMTA @PROVO1.MTA 
LOAD DELAY, DELAY 10 

LOAD address space=gwia GWVOLASYSTEMIGWIA @GWIA.CFG 
protection restart gwia 


Ki » 


Timeout (secs) |600 


Page Options... | OK Cancel [Can] Help | 


NOTE: The set commands are needed in the load script only when the MTA and the Internet Agent are 
not running in protected memory. The address space parameters are needed in the load commands only 
when the MTA and the Internet Agent are running in protected memory. 


4 Click Apply to save the load script. 


5 Ifnecessary, click OK to confirm that you must offline and then online the volume resource 
in order for the changes to take effect. 


6 Continue with “Modifying the Volume Resource Unload Script for the Internet Agent” on 
page 71. 


Modifying the Volume Resource Unload Script for the Internet Agent 


The volume resource unload script executes whenever the Internet Agent volume goes offline. 
Programs should be unloaded in the reverse order of how they were loaded. This ensures that 
supporting programs are not unloaded before programs that rely on them in order to function 


properly. 
To set up the unload script: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume SERVER), 
click Unload to display the default volume resource unload script. 


The next step assumes that this is the first time you have edited this unload script. If other 
GroupWise agents are already running from this volume, some of the modifications will 
already have been made. 


2 Make the following changes to the default unload script: 


+ Ifyou selected Yes under Load Internet Agent and Its MTA in Protected Memory 
(internet Agent Clustering Worksheet item 8), add an unload address space command and 
an unload kill address space command to ensure that the address space is completely 
cleaned up. 


unload address space=addr_space_name 
unload kill address space=addr_space_name 


If your system seems to be trying to kill the address space before the Internet Agent and 
its MTA have been completely unloaded, resulting in the agents hanging in the unloading 
state, set a delay of several seconds before issuing the unload kill address space command 
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to allow the Internet Agent and its MTA adequate time to unload completely. The length 
of the delay varies from system to system; ten seconds is a good starting place. 


unload address space=addr_space_name 
delay 10 
unload kill address space=addr_space_name 


+ Ifyou selected No under Load Internet Agent and Its MTA in Protected Memory? 


(Internet Agent Clustering Worksheet items 8), create an unload command parallel to 
each load command that you placed in the load script. 


unload volume:\system\gwia.nlm 
unload volume:\system\gwmta.nlm 


+ OnNetWare 5.1, if you are using SLP as a short name resolution method, add the cvsbind 


del command for the Internet Agent volume to the unload script. 


cvsbind del cluster volume SERVER IP address 


+ Remove the trustmig command just like you did in the load script. 


The result would look similar to the following example: 


Properties of GWYOL_SERVER [x] 


P Address | Load Unload 


Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fol 


Script 


unload address space = gwia á 


del secondary ipaddress 123.45.67.18 

NUDP DEL GW-CLUSTER_GWVOL_SERVER 123.45.67.18 

cysbind del GW-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 
dismount GWVOL force 

nss forcedeactivate=GWVOL 


4 of 


Timeout (secs) foo 


Page Options... | OK | Cancel [Can ] Help | 


3 Click Apply to save the unload script. 


4 If necessary, click OK to confirm that you must offline and then online the volume resource 
in order for the changes to take effect. 


5 Continue with “Setting the Failover Path and Policies for the Internet Agent” on page 72. 
Setting the Failover Path and Policies for the Internet Agent 


To modify the failover path and policies for the Internet Agent volume resource: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume SERVER), 
click Nodes to display the default failover path for the Internet Agent volume resource. 
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GW-CLUSTER1 
ÉP GW-CLUSTER2 
ÉP GW-CLUSTER3 
ÉP GW-CLUSTER4S 


2 Arrange the nodes in the cluster into the desired failover path for the Internet Agent volume 
(Internet Agent Clustering Worksheet item 3). 


3 Click Apply to save the failover path. 
4 Click Policies to display the default start, failover, and failback policies. 


Properties of GWYOL_SERYER 


The default policy settings are often appropriate. By default, a volume resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the next node in its failover path 


¢ Continues running at its failover location, even after its most preferred node is again 
available 


If you are considering changing these defaults, see the applicable section of Novell Cluster 
Services Overview and Installation for your version of NetWare: 


NetWare 6.x: “Set Start, Failover, and Failback Modes” 
NetWare 5.1: “Set Start, Failover, and Failback Modes” 
5 Click OK when you are finished editing the Internet Agent volume resource properties. 


6 Continue with “Enabling Internet Addressing for Your Clustered GroupWise System” on 
page 74. 
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Enabling Internet Addressing for Your Clustered GroupWise System 


Setting up Internet addressing for a clustered Internet Agent is no different from setting it up for 
an Internet Agent in a any other environment. Follow the instructions in “Enabling Internet 
Addressing” in “System” in the GroupWise 6.5 Administration Guide, then return to this point. 


Verifying GWIA Object Properties 


During installation of the Internet Agent, the GWIA object should have been configured correctly. 
However, it can be helpful to verify certain cluster-specific information in order to familiarize 
yourself with the configuration of a clustered Internet Agent. 


+ “Accessing GWIA Object Properties” on page 74 

+ “Verifying the Reference to the Volume Resource” on page 74 

+ “Verifying the Reference to the Virtual Server” on page 74 

+ “Verifying Post Office Links” on page 74 

+ “Forcing Use of the Internet Agent Secondary IP Address” on page 75 


Accessing GWIA Object Properties 


1 In ConsoleOne, browse to and select the Internet Agent domain in order to display its 
contents. 


2 Right-click the GWIA object, then click Properties. 


3 Continue with “Verifying the Reference to the Volume Resource” on page 74. 


Verifying the Reference to the Volume Resource 
In the GWIA object properties pages: 
1 Click SMTP/MIME > Settings. 
2 Verify the contents of the Hostname/DNS "A Record" Name field. 


It displays the hostname as currently configured in DNS. It should match the Volume 
Resource object name (volume_SERVER) of the Internet Agent volume, not the name of a 
physical server in the cluster. 


3 Make changes if necessary. 


4 Continue with “Verifying the Reference to the Virtual Server” on page 74. 


Verifying the Reference to the Virtual Server 
In the GWIA object properties pages: 
1 Click Server Directories. 


2 Verify that the displayed directories match the virtual server name 
(cluster_volume_SERVER) associated with the Volume Resource object, not the name of a 
physical server in the cluster. 


3 Make changes if necessary. 


4 Continue with “Verifying Post Office Links” on page 74. 


Verifying Post Office Links 
In the GWIA object properties pages: 
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4 Click Post Office Links. 


2 Verify that the Access Mode column displays C/S (for client/server mode) for all post offices 
serviced by the Internet Agent. 


3 Verify that the Links column displays the secondary IP addresses of the GroupWise volumes 
where post offices reside, not the IP addresses of any physical servers in the cluster. 


4 Make changes if necessary. 


5 Continue with “Forcing Use of the Internet Agent Secondary IP Address” on page 75. 


Forcing Use of the Internet Agent Secondary IP Address 


If you want the Internet Agent to send outgoing messages on its secondary IP address, rather than 
using the default of its primary IP address: 


1 Click GroupWise > Network Address. 


2 Inthe TCP/IP Address field, provide the secondary IP address (under Internet Agent 
Clustering Worksheet item 1) for the Internet Agent to use for sending outgoing messages. 


3 Click SMTP/MIME, then click Settings. 

4 Select Bind to TCIP/IP Address at Connection Time. 

5 Click OK. 

6 Continue with “Testing the Clustered Internet Agent” on page 75. 


Testing the Clustered Internet Agent 


After you have configured the Internet Agent volume resource, you can test the load and unload 
scripts by bringing the Internet Agent volume online and taking it offline again. 


1 In ConsoleOne, select the Cluster object, then click View > Cluster State. 


Cluster State | Event Log | HTML Report} 
p gw-cluster Epoch 1 Connected 


GW-CLUSTER1 GW-CLUSTER2 


ooo K ooh Tomar eo Mon jpo or po eo ooN fons 
0 20 40 60 80 100 


Resources Available (%) 
upita 
20 40 60 80 100 


F Available (%) 


Cluster Resource State Location #Lives 
@ GWVOL_SERVER | Offline GW-CLUSTER1 2 | 
GW-CLUSTER1 


@ ILVOL_SERVER Running | 2 


The new Internet Agent volume resource shows Offline in the State column. 


2 Click the new Internet Agent volume resource, then click Online. 
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Cluster State | Event Log | HTML Report| 
p gw-cluster Epoch 1 Connected 


GW-CLUSTER1 GW-CLUSTER2 


r Nodes Available (%) > Resources Available (%) 


fi Ci (jo OCT 
0 20 40 6&0 80 100 


Cluster Resource State Location #Lives 
@ GWVOL_SERVER | Running GW-CLUSTER1 2 | 


@ ILVOL_SERVER Running | GW-CLUSTER1 2 


The State column for the volume resource now displays Running. 


3 Observe the server console where the Internet Agent and its MTA are loading to see that they 
start and run correctly. 


If you are using protected memory, you can use the protection command at the server console 
prompt to list all the address spaces on the node and what NLM programs are running in each 
one. 


4 Click the new Internet Agent volume resource, then click Offline. 
The State column for the volume resource returns to Offline. 


5 Observe the server console where the Internet Agent and its MTA are unloading to see that 
they shut down correctly. 


If you are using protected memory, you can use the protection command again to make sure 
that the address space used by the Internet Agent and its MTA is no longer present. 


6 Repeat Step 2 whenever you are ready to bring the new Internet Agent volume resource online 
permanently. 


On NetWare 6.x, these actions can also be performed from your Web browser. See “Using 
NetWare Remote Manager on NetWare 6.x” on page 55. 


7 Continue with “Managing the Internet Agent in a Cluster” on page 76. 


Managing the Internet Agent in a Cluster 


After you have installed the Internet Agent in a cluster, you should consider some long-term 
management issues. 


+ “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 76 
+ “Knowing What to Expect in an Internet Agent Failover Situation” on page 77 


Updating GroupWise Objects with Cluster-Specific Descriptions 


76 


After installing the Internet Agent in your clustered GroupWise system, while the cluster-specific 
information is fresh in your mind, you should record that cluster-specific information as part of the 
Group Wise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the 
information recorded in the GroupWise objects if the configuration of your system changes. 


+ “Recording Cluster-Specific Information about the Internet Agent Domain and Its MTA” on 
page 77 


+ “Recording Cluster-Specific Information about the Internet Agent” on page 77 
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Recording Cluster-Specific Information about the Internet Agent Domain and Its MTA 
To permanently record important cluster-specific information for the Internet Agent domain: 
1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 In the Description field of the Internet Agent domain Identification page, provide a cluster- 
specific description of the Internet Agent domain, including the secondary IP address of its 
cluster-enabled volume and the cluster-unique port numbers used by its MTA. 


Click OK to save the Internet Agent domain description. 
Select the Internet Agent Domain object to display its contents. 


Right-click the MTA object, then click Properties. 


og bh GQ 


In the Description field of the MTA Identification page, record the secondary IP address of 
the cluster-enabled Internet Agent domain volume and the cluster-unique port numbers used 
by the MTA. 


This information will appear on the MTA console, no matter which node in the cluster it is 
currently running on. 


7 Click OK to save the MTA description. 


8 Continue with “Recording Cluster-Specific Information about the Internet Agent” on page 77. 


Recording Cluster-Specific Information about the Internet Agent 


With the contents of the Internet Agent domain still displayed: 
1 Right-click the GWIA object, then click Properties. 
2 Click GroupWise, then click Identification. 


3 Inthe Description field, record the secondary IP address of the cluster-enabled Internet Agent 
domain volume and the cluster-unique port numbers used by the Internet Agent. 


This information will appear on the Internet Agent console, no matter which node in the 
cluster it is currently running on. 


4 Click OK to save the Internet Agent information. 
5 Continue with “Knowing What to Expect in an Internet Agent Failover Situation” on page 77. 


Knowing What to Expect in an Internet Agent Failover Situation 


The failover behavior of the MTA for the Internet Agent domain will be the same as for an MTA 
in a regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on 
page 58. 


Failover of the Internet Agent itself is more complex. The various clients (POP3, IMAP4, and 
LDAP) will receive an error message that the node is not available. Most of the clients do not 
attempt to reconnect automatically, so the user must exit the Group Wise client and restart it to 
reestablish the connection after the failover process is complete. Fortunately, the Internet Agent 
restarts quickly in its failover location so users will be able to reconnect quickly. 


As with the MTA and the POA, migration of the Internet Agent takes longer than failover. In fact, 
the Internet Agent can seem especially slow to shut down properly, as it finishes its normal 
processing and stops its threads. For a busy Internet Agent, you might need to wait several minutes 
for it to shut down properly. 
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Internet Agent Clustering Worksheet 


Item 


1) Shared Volume for Internet Agent: 


Cluster Enabled? 


+ Yes (highly recommended) 


Cluster volume IP address 


+ No 


2) Internet Agent 
Domain Name: 


Domain Database Location: 


3) Internet Agent 
Failover Path: 


4) MTA Installation Location: 
¢ vol:\system on Internet Agent volume 


¢ sys:\system on each node 
Consolidate multiple MTA startup 
files on Internet Agent volume? 


5) MTA Network Information: 
+ MTA IP address 

+ MTA message transfer port 
+ MTA live remote port 

+ MTA HTTP port 

6) Internet Agent 

Installation Location: 


¢ vol:\system on the Internet Agent 
volume 


¢ sys:\system on each node 
Consolidate multiple Internet Agent 
configuration files on Internet Agent 
volume? 


7) Internet Agent 
Network Information: 


¢ Internet Agent IP address 


+ Internet Agent HTTP port 


Explanation 


Specify the name (cluster_volume) of the shared volume where the Internet Agent 
domain will be created. 


For cluster-enabling, specify the IP addresses of the virtual server 
(volume_SERVER.cluster) to which the cluster-enabled volume is tied. 


For more information, see “Deciding Whether to Cluster-Enable the Internet Agent 
Volume” on page 64. 


Specify a unique name for the Internet Agent domain. Specify the directory on the 
Internet Agent volume where you want to create the new domain. 


For more information, see “Planning a Domain for the Internet Agent” on page 64. 


List other nodes in the cluster where the Internet Agent and its MTA could fail over. 


For more information, see “Determining an Appropriate Failover Path for the Internet 
Agent Volume” on page 64. 


Mark the location where you will install the MTA software. If necessary, specify the 
location where you will consolidate multiple MTA startup files on an Internet Agent 
volume. 


For more information, see “Deciding Where to Install the Internet Agent and Its MTA” 
on page 66. 
Gather the MTA network address information from the Internet Agent section of the 


“IP Address Worksheet” on page 34. 


For more information, see “Planning a Secondary IP Address and Cluster-Unique 
Port Numbers for the Internet Agent and Its MTA” on page 65. 


Mark the location where you will install the Internet Agent software. 


If necessary, specify the location where you will consolidate multiple Internet Agent 
configuration files (gwia.cfg) on an Internet Agent volume. 


For more information, see “Deciding Where to Install the Internet Agent and Its MTA” 
on page 66. 


Gather the Internet Agent network address information from the Internet Agent 
section of the “IP Address Worksheet” on page 34. 


For more information, see “Planning a Secondary IP Address and Cluster-Unique 
Port Numbers for the Internet Agent and Its MTA” on page 65. 
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Item 


Explanation 


8) Load Internet Agent and Its MTA 
in Protected Memory? 


+ No 

+ Yes 

Protected address space names: 
+ MTA: 


¢ Internet Agent: 


Mark whether you need to run the Internet Agent and its MTA in protected memory. 
If so, specify a unique address space for each agent. 


IMPORTANT: We strongly recommend that you run the Internet Agent and its MTA 
in protected memory and mark each memory space as restartable. 


For more information, see “Deciding Whether to Run the Internet Agent and Its MTA 
in Protected Memory” on page 66. 
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Internet Agent Quick Checklist 


&0 


Q) Plan the new clustered Internet Agent, including the new domain required to house the 


Internet Agent in a clustering environment. 
See “Planning the Internet Agent in a Cluster” on page 63. 
Make sure your firewall is configured to accommodate the Internet Agent. 
See “Preparing Your Firewall for the Internet Agent” on page 65. 
Cluster-enable the volume where the Internet Agent domain will reside. 
See “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent” on page 88. 
Create the new Internet Agent domain. 
See “Creating a Domain for the Internet Agent” on page 68. 
Set up the MTA for the new Internet Agent domain. 
See “Installing the MTA for the Internet Agent Domain” on page 68. 
Install the Internet Agent. 
See “Installing the Internet Agent Software in a Cluster” on page 68. 
Modify the Internet Agent volume resource load script: 

+ Remove the trustmig command 

+ Add the cvsbind add command (NetWare 5.1 only; optional) 

+ Add the search add command (optional) 


+ Ifyou will not run the MTA and the Internet Agent in protected memory, add the set auto 
restart commands and the set developer option = off command 


+ Add the load commands for the MTA and the Internet Agent, separating them with a 
delay command 


+ If you will run the MTA and the Internet Agent in protected memory, add the address 
space parameter to the load commands and add a protection restart command for the 
address space 


See “Modifying the Volume Resource Load Script for the Internet Agent” on page 69. 
Modify the Internet Agent volume resource unload script: 
+ Add the MTA and Internet Agent or address space unload command(s) 


+ Add the cvsbind del command if you used the cvsbind add command in the load script 
(NetWare 5.1 only; optional) 


+ Remove the trustmig command 
See “Modifying the Volume Resource Unload Script for the Internet Agent” on page 71. 
Set up the Internet Agent volume failover path and policies. 
See “Setting the Failover Path and Policies for the Internet Agent” on page 72. 
Enable Internet Addressing for the clustered Internet Agent. 
See “Enabling Internet Addressing for Your Clustered GroupWise System” on page 74. 
Double-check the cluster-specific GWIA object properties. 
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See “Verifying GWIA Object Properties” on page 74. 
0 Test the clustered Internet Agent. 
See “Testing the Clustered Internet Agent” on page 75. 


ü Record cluster-specific information in the properties pages of the Group Wise objects 
associated with the Internet Agent. 


See “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 76. 
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Implementing WebAccess in a Novell Cluster 


You should already have set up at least a basic GroupWise™ system, as described in Chapter 2, 
“Planning GroupWise in a Novell Cluster,” on page 17 and Chapter 3, “Setting Up a Domain and 
Post Office in a Novell Cluster,” on page 37. As part of this process, the “System Clustering 
Worksheet” on page 32 and the “IP Address Worksheet” on page 34 were filled out. If you do not 
have access to the filled-out worksheets, print the worksheets now and fill in the clustering and 
network address information as it currently exists on your system. You will need this information 
as you implement WebAccess in a cluster. 


+ “Understanding the WebAccess Components” on page 83 
+ “Planning WebAccess in a Cluster” on page 83 

+ “Setting Up WebAccess in a Cluster” on page 88 

+ “Managing WebAccess in a Cluster” on page 96 

+ “WebAccess Clustering Worksheet” on page 99 

+ “WebAccess Quick Checklist” on page 101 


Understanding the WebAccess Components 


If you are not familiar with GroupWise WebAccess, review “GroupWise WebAccess Overview” 
in “Installing GroupWise WebAccess” in the GroupWise 6.5 Installation Guide. 


As you plan WebAccess in a clustering environment, you must keep in mind that you will plan and 
set up two WebAccess components: 


+ WebAccess Agent (gwinter.nlm) that will be associated with a GroupWise WebAccess 
domain 


+ WebAccess Application (a Java* servlet) that will be added to your Web server (Netscape 
Enterprise Server for NetWare® required on NetWare 6) 


Planning WebAccess in a Cluster 


A main system configuration difference between a GroupWise system in a clustering environment 
and a GroupWise system in a regular environment is that you need to create a separate domain to 
house each GroupWise gateway, including the WebAccess Agent. 


The “WebAccess Clustering Worksheet” on page 99 lists all the information you will need as you 
set up the WebAccess Agent and the WebAccess Application in a clustering environment. You 
should print the worksheet and fill it out as you complete the tasks listed below: 


+ “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” on 
page 84 
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+ “Planning a New Domain for the WebAccess Agent” on page 85 
+ “Deciding Whether to Cluster-Enable the WebAccess Agent Volume” on page 85 
+ “Determining an Appropriate Failover Path for the WebAccess Agent Volume” on page 85 


+ “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the WebAccess 
Agent and Its MTA” on page 86 


+ “Deciding Where to Install the WebAccess Agent and Its MTA” on page 86 

+ “Deciding Whether to Run the WebAccess Agent and Its MTA in Protected Memory” on 
page 86 

+ “Planning the MTA Installation” on page 87 

+ “Planning the WebAccess Installation” on page 87 


IMPORTANT: NetWare 6.5 provides Apache and Tomcat instead of the Netscape Enterprise Web Server, 
which was provided on NetWare 6. However, NetWare 6.5 Support Packs currently cannot update an Apache/ 
Tomcat installation that is located on cluster-enabled volume. Consequently, clustering WebAccess with 
Apache and Tomcat is not currently supported by Novell. However, helpful instructions are available from Tay 
Kratzer at www.taykratzer.com. 


Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on 


NetWare 6 


Although several Web servers are supported for use with GroupWise WebAccess in a non- 
clustered environment, only the Netscape Enterprise Server for NetWare is supported in a 
clustering environment because it is the only currently supported Web server that runs on NetWare 
6. In preparation for installing WebAccess in your clustered GroupWise system, install and set up 
the Netscape Enterprise Server for NetWare, following the instructions in “Configuring NetWare 
Enterprise Web Server with Novell Cluster Services” in NetWare Cluster Services Resource 
Configuration Guide. 


As you set up the Netscape Enterprise Server, record the following key configuration information 
on the WebAccess Clustering Worksheet: 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 10: Physical Web Servers, list the physical NetWare servers where you are installing the 
Netscape Enterprise Server software. 


Under Item 11: Netscape Enterprise Server IP Address, record the secondary IP address of the 
Netscape Enterprise Server cluster resource that you create. 


Under Item 12: Netscape Enterprise Server Mode, mark whether you have configured the Netscape 
Enterprise Server to run in active/active or active/passive mode. In active/active mode, the Netscape 
Enterprise Server runs on multiple nodes simultaneously; this is the recommended mode. 


Under Item 13: Netscape Enterprise Server Failover Path, list the nodes in the cluster where you want 
the Netscape Enterprise Server cluster resource to fail over. 


Under Item 14: Hardware Virtual Server Information, record the dedicated IP address for the Web site 
and the document root directory. 


The Netscape Enterprise Server for NetWare does not depend on the functionality of cluster- 
enabled volumes the way GroupWise does. Because the WebAccess Application will be installed 
to a subdirectory of the Netscape Enterprise Server installation directory 
(sys:\novonyx\suitespot\docs\com\novell\webaccess), the WebAccess Application cannot be 
installed on a cluster-enabled volume. Instead, you will install it to the sys: volume on each node 
where the Netscape Enterprise Server has been installed. 
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Planning a New Domain for the WebAccess Agent 


The considerations involved in planning a domain for the WebAccess Agent are much the same as 
planning any other domain. In preparation, review “Planning a New Domain’, then print and fill 
out the “Domain Worksheet” in “Domains” in the GroupWise 6.5 Administration Guide. 


Keep in mind the following cluster-specific details: 


+ When you specify the location for the domain directory on the Domain Worksheet, include 
the shared volume where you want the domain directory to reside. 


+ Do not concern yourself with the GroupWise agent information on the Domain Worksheet. 
You can stop with item 10. You will plan the MTA installation later. 


When you have completed the Domain Worksheet, transfer the key information from the Domain 
Worksheet to the WebAccess Clustering Worksheet. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 1: Shared Volume for WebAccess Agent, transfer the domain location from the Domain 
Worksheet to the WebAccess Clustering Worksheet. 


Under Item 2: WebAccess Agent Domain Name, transfer the domain name and database directory 
from the Domain Worksheet to the WebAccess Clustering Worksheet. 


Deciding Whether to Cluster-Enable the WebAccess Agent Volume 


You should plan to cluster-enable the shared volume where the WebAccess Agent domain will 
reside. For a review of the benefits of cluster-enabling volumes, see “Deciding Whether to Cluster- 
Enable the Shared Volumes Used by GroupWise” on page 21, which describes the issues in the 
context of planning MTA and POA installations. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 1: Shared Volume for WebAccess Agent, mark Yes under Cluster Enabled?. 


Cluster-enabling relies on successful short name resolution throughout your system. Review 
“Ensuring Successful Name Resolution for GroupWise Volumes” on page 23, which describes the 
issues in the context of planning MTA and POA installations. 


Determining an Appropriate Failover Path for the WebAccess Agent Volume 


As with the MTA and the POA, you need to decide which nodes in the cluster would be appropriate 
locations where the WebAccess Agent volume could fail over. For a review of failover paths, see 
“Determining Appropriate Failover Paths for the Agents” on page 27, which describes the issues 
in the context of planning MTA and POA installations. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 4: WebAccess Agent Failover Path, list the nodes that you want to have in the WebAccess 
Agent volume failover path. 
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Planning a Secondary IP Address and Cluster-Unique Port Numbers for the 
WebAccess Agent and Its MTA 


As with the MTA and the POA, the WebAccess Agent needs a secondary IP address and cluster- 
unique port numbers. As part of planning to install the MTA and POA, you should already have 
determined the secondary IP address and cluster-unique port numbers for the WebAccess Agent 
and its MTA as you filled out the “IP Address Worksheet” on page 34. If you do not have a filled- 
out copy of this worksheet for your system, print it now and fill in current system information. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 6: MTA Network Information, transfer the MTA secondary IP address and cluster-unique 
port numbers from the WebAccess section the IP Address Worksheet to the WebAccess Clustering 
Worksheet. 


Under Item 1: Shared Volume for WebAccess Agent, copy the MTA secondary IP address under 
Cluster Volume IP Address as well, because they are the same. 


Under Item 8: WebAccess Agent Network Information, transfer the WebAccess Agent secondary IP 
address (the same as for its MTA) and the cluster-unique WebAccess Agent port number from the 
WebAccess section of the IP Address Worksheet to the WebAccess Clustering Worksheet. 


Deciding Where to Install the WebAccess Agent and Its MTA 


As with the MTA and the POA, you can choose to install the WebAccess Agent and its MTA to 
the sys:\system directory of each node or to a vol:\system directory on the WebAccess Agent 
volume. For a discussion of these alternatives, see “Deciding Where to Install the Agent Software” 
on page 28, which describes the issues in the context of planning MTA and POA installations. If 
you only have one WebAccess Agent for your GroupWise system with several nodes in its failover 
path, it is an easy choice. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 5: MTA Installation Location and Item 7: WebAccess Agent Installation Location, mark 
whether you will install the WebAccess Agent and its MTA to sys:\system on each node in the cluster 
or to a vol:\system directory on the WebAccess Agent volume. Also specify where the MTA startup file 
will be stored. 


Deciding Whether to Run the WebAccess Agent and Its MTA in Protected Memory 


&6 


As with the MTA and the POA, you can choose whether to run the WebAccess Agent in protected 
memory. For a review of the benefits of protected memory, see “Deciding Whether to Run the 
Agents in Protected Memory” on page 30, which describes the issues in the context of planning 
MTA and POA installations. 


You might think that protected memory would not be necessary if you have only one WebAccess 
Agent for your GroupWise system because it could never fail over to a node where another 
WebAccess Agent was running. However, because the WebAccess Agent in a cluster is installed 
into its own domain with its own MTA, this MTA could fail over to a node where another MTA 
was already running. Therefore, it is safest to load the WebAccess Agent and its MTA into 
protected memory. Load each agent into its own memory space and mark each memory space as 
restartable. 
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WEBACCESS CLUSTERING WORKSHEET 


Under Item 8: Load WebAccess Agent and Its MTA in Protected Memory?, mark whether you need to 
run the WebAccess Agent and its MTA in protected memory. If you do, provide a protected memory 
address space name for each agent. 


Planning the MTA Installation 


Follow the instructions in “Planning the NetWare Agent Installation” on page 30, then return to 
this point. After you follow the instructions, you will have a filled-out NetWare® Agent Worksheet 
to use when you install the MTA. 


IMPORTANT: Do not install the NetWare MTA until you are instructed to do so in “Setting Up WebAccess in 
a Cluster” on page 88. 


Planning the WebAccess Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install WebAccess are the same in a clustering environment as for any other 
environment. Review “Planning GroupWise WebAccess”, then print and fill out the “GroupWise 
WebAccess Installation Worksheet” in “Installing GroupWise WebAccess” in the GroupWise 6.5 
Installation Guide. When you set up WebAccess in a cluster, you will install the WebAccess Agent 
and the WebAccess Application in two separate steps: 


+ “Planning the WebAccess Agent Installation” on page 87 
+ “Planning the WebAccess Application Installation” on page 87 
IMPORTANT: Do not install the WebAccess software until you are instructed to do so in “Setting Up 


WebAccess in a Cluster” on page 88. 


Planning the WebAccess Agent Installation 


For the WebAccess Agent, fill out items 2 through 12 on the GroupWise WebAccess Installation 
Worksheet, taking into account the following cluster-specific issues: 


WEBACCESS INSTALLATION WORKSHEET 


Under Item 2: Installation Directory, take into account your decision recorded on the WebAccess 
Clustering Worksheet (Item 7: WebAccess Agent Installation Location). 


Under Item 3: Server Address, transfer the IP address and port number from the WebAccess 
Clustering Worksheet (Item 8: WebAccess Agent Network Information) filled out during “Planning a 
Secondary IP Address and Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on 
page 86. 


Under Item 4: Enable Clustering Support?, mark Yes. This will cause the WebAccess Installation 
program to customize the WebAccess files for clustering. 


Under Item 5: Domain Directory Path, transfer the domain directory from the Domain Worksheet you 
filled out during “Planning a New Domain for the WebAccess Agent” on page 85. 


Planning the WebAccess Application Installation 


For the WebAccess Application, fill out items 13 through 19 on the GroupWise WebAccess 
Installation Worksheet, taking into account the following cluster-specific issues: 
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WEBACCESS INSTALLATION WORKSHEET 


Under Item 13: Web Server Type and Root Directory, mark Netscape Enterprise Server for NetWare 
if you are using NetWare 6. No other Web server is currently supported for use with GroupWise and 


Novell® Cluster Services™. The Web server root directory will be sys:\novonyx\suitespot. 


Under Item 16: Novell Root Directory, do not choose a location on a cluster-enabled volume if you 
are running the Netscape Enterprise Server in active/active mode; it must be a directory on the sys: 
volume of the server. If you are using active/passive mode, you can choose a location on a cluster- 
enabled volume. Just make sure that the Volume Resource load script mounts the volume before 
starting the Netscape Enterprise Server. 


Setting Up WebAccess in a Cluster 


You should already have reviewed “Planning WebAccess in a Cluster” on page 83 and filled out 
the “WebAccess Clustering Worksheet” on page 99. You are now ready to complete the following 
tasks to set up the WebAccess Agent in a clustering environment: 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


“Cluster-Enabling a Shared Volume for Use with the WebAccess Agent” on page 88 
“Creating a Domain for the WebAccess Agent” on page 89 

“Installing the MTA for the WebAccess Agent Domain” on page 89 

“Installing and Configuring the WebAccess Agent in a Cluster” on page 89 
“Installing and Configuring the WebAccess Application in a Cluster” on page 95 
“Testing Your Clustered WebAccess Installation” on page 96 


“Managing WebAccess in a Cluster” on page 96 


IMPORTANT: NetWare 6.5 provides Apache and Tomcat instead of the Netscape Enterprise Web Server, 
which was provided on NetWare 6. However, NetWare 6.5 Support Packs currently cannot update an Apache/ 
Tomcat installation that is located on cluster-enabled volume. Consequently, clustering WebAccess with 
Apache and Tomcat is not currently supported by Novell. However, helpful instructions are available from Tay 
Kratzer at www.taykratzer.com. 


Cluster-Enabling a Shared Volume for Use with the WebAccess Agent 


1 


Complete the steps in the applicable section of Novell Cluster Services Overview and 
Installation for your version of NetWare: 


+ NetWare 6.x: “Cluster Enable Pools and Volumes” 
+ NetWare 5.1: “Cluster-Enable Volumes ” 


The WebAccess Clustering Worksheet provides the volume to cluster-enable, the cluster- 
enabled volume IP address, and the failover path for the WebAccess volume. 


For a review of the new Novell eDirectory™ objects that are created when you cluster-enable 
a shared volume, see “Deciding Whether to Cluster-Enable the Shared Volumes Used by 
GroupWise” on page 21. 


If you have installed the latest version of ConsoleOne® and the Novell Cluster Services snap- 
in, as described in “Updating to the Latest ConsoleOne Snap-In” on page 18, you will be able 
to rename the cluster-related objects in case your DNS name server cannot resolve object 
names that include the underscore (_) character. 
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2 To ensure successful short name resolution, add entries for the WebAccess Agent virtual 
server to support your preferred methods of short name resolution, as described in 
“Configuring Short Name Resolution” on page 38. 


3 Continue with “Creating a Domain for the WebAccess Agent” on page 89. 


Creating a Domain for the WebAccess Agent 


The WebAccess Agent domain will be a secondary domain. To create it, follow the instructions in 
“Creating a New Secondary Domain in a Cluster” on page 42, taking your information from the 
WebAccess Clustering Worksheet, rather than the System Clustering Worksheet, then return to this 
point. 


Do not create any post offices in the WebAccess Agent domain. 


Continue with “Installing the MTA for the WebAccess Agent Domain” on page 89. 


Installing the MTA for the WebAccess Agent Domain 


The MTA for the WebAccess Agent domain can be installed just like any other MTA in your 
clustered GroupWise system. Follow the instructions in “Installing the Agent Software in a 
Cluster” on page 45, then return to this point. 


You do not need to edit the MTA startup file. You do not need to modify the Volume Resource 
properties until after you have installed the WebAccess Agent. 


Continue with “Installing and Configuring the WebAccess Agent in a Cluster” on page 89. 


Installing and Configuring the WebAccess Agent in a Cluster 


After you have created a domain for the WebAccess Agent and installed the MTA for that domain, 
you are ready to install and configure the WebAccess Agent. 


+ “Installing the WebAccess Agent Software in a Cluster” on page 89 


+ “Configuring the WebAccess Agent Volume Resource to Load and Unload the WebAccess 
Agent and Its MTA” on page 90 


Installing the WebAccess Agent Software in a Cluster 


The WebAccess Agent is the component of your WebAccess installation that accesses post offices 
and libraries to retrieve information for WebAccess client users. 


41 Map a drive to the WebAccess Agent volume (WebAccess Clustering Worksheet item 1) 
where the WebAccess domain is located. 


The WebAccess Agent volume name will be cluster_volume. For assistance with mapping a 
drive to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 38. 


2 Ifyou selected vol:\system on WebAccess Agent volume as the WebAccess Agent installation 
location (WebAccess Clustering Worksheet item 7), create the vol:\system directory on the 
WebAccess Agent volume accessed in Step 1. 


or 


if you selected sys:\system on each node, decide which node you will install the WebAccess 
agent to first, then map a drive to its sys:\system directory. 


Implementing WebAccess in a Novell Cluster 89 


3 Start the WebAccess Installation program and install the NetWare WebAccess Agent, 
following Step | through Step 5 provided in “Installing the WebAccess Agent” in “Installing 
Group Wise WebAccess” in the Group Wise 6.5 Installation Guide. Keep in mind the following 
cluster-specific details: 


+ Inthe Components dialog box, select only GroupWise WebAccess Agent. 
Do not install the WebAccess Application at this time. 


+ Use items 2 through 12 on the GroupWise WebAccess Installation Worksheet that you 
filled out during “Planning the WebAccess Installation” on page 87 to fill in the fields 
during the WebAccess Agent installation process. 


+ Inthe Network Address dialog box, select Configure GroupWise Agents for Clustering. 


+ Inthe Installation Path dialog box, be sure to browse through the drive you mapped to the 
location you chose in Step 2 above. 


+ Inthe Gateway Directory dialog box, be sure to browse to the domain directory through 
the drive you mapped in Step | above. 


+ In the Start Applications dialog box, deselect Start the GroupWise WebAccess Agent. 


+ The WebAccess Installation program creates the strtweb.ncf and stopweb.ncf files, which 
include the load and unload commands for the WebAccess Agent. You will use this 
information later when you create the load and unload scripts for the WebAccess Volume 
Resource object. 


4 If you need to install the WebAccess Agent to sys:\system on multiple nodes in the cluster, 
repeat Step 4, mapping new drives as needed. 


5 Make sure you have completed all the WebAccess Agent tasks described in “Setting Up 
GroupWise WebAccess on NetWare or Windows” in “Installing GroupWise WebAccess” in 
the GroupWise 6.5 Installation Guide, but do not start the WebAccess Agent at this time. 


6 Continue with “Configuring the WebAccess Agent Volume Resource to Load and Unload the 
WebAccess Agent and Its MTA” on page 90. 
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90 


The properties of the Volume Resource object define how the WebAccess Agent volume functions 
within the cluster, how NLM programs are loaded and unloaded, and how failover and failback 
situations are handled. Complete the following tasks for the WebAccess Agent volume: 


+ “Modifying the Volume Resource Load Script for the WebAccess Agent” on page 90 
+ “Modifying the Volume Resource Unload Script for the WebAccess Agent” on page 92 
¢ “Setting the Failover Path and Policies for the WebAccess Agent” on page 94 


Modifying the Volume Resource Load Script for the WebAccess Agent 
The volume resource load script executes whenever the WebAccess Agent volume comes online. 
To set up the load script: 
1 In ConsoleOne, browse to and select the Cluster object. 
If necessary, click View > Console View to display its contents. 


2 Right-click the Volume Resource object (volume SERVER), then click Properties > Load to 
display the default volume resource load script for the WebAccess Agent volume. 
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The next step assumes that this is the first time you have edited the load script. If other 
Group Wise agents are already running from this volume, some of the modifications will 
already have been made. 


Make the following changes to the default load script: 


+ 


Remove the trustmig command. It is not necessary to migrate trustees for the WebAccess 
Agent volume. Removing this line helps the load script to execute faster. 


On NetWare 5.1, if you are using SLP as a short name resolution method, as described in 
“Configuring Short Name Resolution” on page 38, add the cvsbind add command for the 
WebAccess Agent volume to the load script. 


cvsbind add cluster volume SERVER IP address 


If you selected vol:\system on WebAccess Agent volume as the installation location 
(WebAccess Clustering Worksheet items 5 and 7), add a search add command to add the 
new vol:\system directory to the server search path. 


search add volume:\system 


If you selected sys:\system on each node as the installation location (WebAccess 
Clustering Worksheet items 5 and 7) but you are storing the MTA startup file on the 
WebAccess Agent volume, add that location to the server search path. 


If you selected No under Load WebAccess Agent and Its MTA in Protected Memory? 
(WebAccess Clustering Worksheet item 9), add the following abend recovery options: 


set auto restart after abend = 2 

set auto restart after abend delay time = 0 
set auto restart down timeout = 60 

set developer option = off 


These settings provide the best possible handling of GroupWise databases in the event 
that an abend should occur within the cluster. 


Transfer the MTA load command from the grpwise.ncf file located in the vol:\system 
directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text into the load 
script page. Then delete or rename the grpwise.ncf file to avoid future confusion. 


load volume:\system\gwmta.nlm @domain.mta 
Add a delay so that the MTA is fully loaded before the WebAccess Agent starts to load: 


load delay 
delay 10 


The length of the delay varies from system to system; ten seconds is a good starting place. 


Transfer the WebAccess Agent load command from the strtweb.ncf file located in the 
vol:\system directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text 
into the load script page. 


load volume:\system\gwinter.nlm 
/ph=volume: \domain\wpgate\webac65a 
/user=username / PASSWORD=password 


If you selected Yes under Load WebAccess Agent and Its MTA in Protected Memory? 
(WebAccess Clustering Worksheet item 9), add the address space parameter to the load 
commands to specify the protected address space where the WebAccess Agent and its 
MTA will run. Add a protection restart command for the address space name. 
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Load address space=addr_space_name 
volume: \system\gwmta.nlm @domain.mta 

load address space=addr_space_ name 
volume: \system\gwinter.nlm 
/ph=volume: \domain\wpgate\webac65a 
/user=username /password=password 

protection restart addr_space_ name 


The result would look similar to the following example: 


Properties of GWYOL_SERVER [x] 


P Address | Load Ez | Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fold 
| Cluster Resource Load Script 


Script 


nss Jactivate=GWWVOL = 
mount GWVOL VOLID=254 

cysbind add GiV-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 

NUDP ADD GW-CLUSTER_GWVOL_SERVER 123.45.67.18 

add secondary ipaddress 123.45.67.18 

search add gwvolisystem 


SET AUTO RESTART AFTER ABEND = 2 

SET AUTO RESTART AFTER ABEND DELAY TIME = 0 
SET AUTO RESTART DOWN TIMEOUT = 60 

SET DEVELOPER OPTION = OFF 


LOAD address space=webacc GY/VOLIASYSTEMIGWMTA @PROVO1.MTA 

LOAD DELAY, DELAY 10 

LOAD address space=webace GYV/VOLASYSTEMIGWINTER /PH=GWYVOLAPROVOTWPGATEWYEBACBDA 
protection restart webacc 


al 5 


Timeout (secs) |600 


Page Options... | OK | Cancel [Cn] Help | 


NOTE: The set commands are needed only when the MTA and the WebAccess Agent are not running in 
protected memory. The address space parameters are needed in the load commands only when the MTA 
and the WebAccess Agent are running in protected memory. 


4 Click Apply to save the load script. 


5 If necessary, click OK to confirm that you must offline and then online the volume resource 
in order for the changes to take effect. 


6 Continue with “Modifying the Volume Resource Unload Script for the WebAccess Agent” on 
page 92. 


Modifying the Volume Resource Unload Script for the WebAccess Agent 


The volume resource unload script executes whenever the WebAccess Agent volume goes offline. 
Programs should be unloaded in the reverse order of how they were loaded. This ensures that 
supporting programs are not unloaded before programs that rely on them in order to function 


properly. 
To set up the unload script: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume SERVER), 
click Unload to display the default volume resource unload script. 


The next step assumes that this is the first time you have edited the unload script. If other 
Group Wise agents are already running from this volume, some of the modifications will 
already have been made. 


2 Make the following changes to the default unload script: 
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+ Ifyou selected Yes under Load WebAccess Agent and Its MTA in Protected Memory 
(WebAccess Clustering Worksheet item 9), add an unload address space command and 
an unload kill address space command to ensure that the address space is completely 
cleaned up. 


unload address space=addr_space_name 
unload kill address space=addr_space_name 


If your system seems to be trying to kill the address space before the WebAccess Agent 
and its MTA have been completely unloaded, resulting in the agents hanging in the 
unloading state, set a delay of several seconds before issuing the unload kill address space 
command to allow the WebAccess Agent and its MTA adequate time to unload 
completely. The length of the delay varies from system to system; ten seconds is a good 
starting place. 


unload address space=addr_space_name 
delay 10 
unload kill address space=addr_space_ name 


+ Ifyou selected No under Load WebAccess Agent and Its MTA in Protected Memory? 
(WebAccess Clustering Worksheet items 9), create an unload command parallel to each 
load command that you placed in the load script. 


unload volume:\system\gwinter.nlm 
unload volume:\system\gwmta.nlm 


+ OnNetWare 5.1, if you are using SLP as a short name resolution method, add the cvsbind 
del command for the WebAccess Agent volume to the unload script. 


cvsbind del cluster volume SERVER ip address 
+ Remove the trustmig command just like you did in the load script. 


The result would look similar to the following example: 


Properties of GWYOL_SERVER [x] 
P Address | Load füh 
1 Soriet i 


Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fold 


Script 


unload address space = webacc a 


del secondary ipaddress 123.45.67.18 

NUDP DEL GW-CLUSTER_GWVOL_SERVER 123.45.67.18 

cysbind del GWV-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 
dismount GWVOL force 

nss /forcedeactivate=GWWVOL 


al » 
Timeout (secs) foo 


Page Options... | OK Cancel [Can] Help | 


3 Click Apply to save the unload script. 


4 If necessary, click OK to confirm that you must offline and then online the volume resource 
in order for the changes to take effect. 


5 Continue with “Setting the Failover Path and Policies for the WebAccess Agent” on page 94. 
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Setting the Failover Path and Policies for the WebAccess Agent 


To modify the failover path and policies for the WebAccess Agent volume resource: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume SERVER), 
click Nodes to display the default failover path for the WebAccess Agent volume resource. 


Properties of GWYOL_SERVER [x] 
IP Address | Load | Unload | Policies Nodes TTT] NDS Rights v | Other | Rights to Files andi 
| luster Resource Preferred Nodes. | 
Unassigned Assigned 


 GW-CLUSTER1 
P GW-CLUSTER2 
 GW-CLUSTER3 
 GW-CLUSTER4S 


Page Options.. | ok | _cancei |[_ Aeey | He | 


2 Arrange the nodes in the cluster into the desired failover path for the WebAccess Agent 
volume (WebAccess Clustering Worksheet item 4). 


3 Click Apply to save the failover path. 
4 Click Policies to display the default start, failover, and failback policies. 


Properties of GWYOL_SERYER [x] 
P Address | Load | Unload | Policies 77T] Nodes | NDS Rights ~ | Other | Rights to Files and Folders | 
| Cluster Resource Policies į 


[P Ignore Quorum 


rStart Mode 
@ Manual C Auto 


; Failover Mode 
C Manual © Auto 


; Failback Mode 
C Manual © Auto © Disable 


Page Options.. | ok | _cancei |[_ Anny | Hel | 


The default policy settings are often appropriate. By default, a volume resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the next node in its failover path 


+ Continues running at its failover location, even after its most preferred node is again 
available 


If you are considering changing these defaults, see the applicable section of Novell Cluster 
Services Overview and Installation for your version of NetWare: 


+ NetWare 6.x: “Set Start, Failover, and Failback Modes” 
+ NetWare 5.1: “Set Start, Failover, and Failback Modes” 
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5 Click OK when you are finished editing the WebAccess Agent volume resource properties. 


6 Continue with “Installing and Configuring the WebAccess Application in a Cluster” on 
page 95. 


Installing and Configuring the WebAccess Application in a Cluster 


Recall that the WebAccess Agent is the component of your WebAccess installation that accesses 
post offices and libraries to retrieve information for WebAccess client users. The WebAccess 
Application provides the link between the WebAccess Agent and the WebAccess clients’ Web 
browsers. 


To install the WebAccess Application: 


1 Map a drive to the WebAccess Agent volume (WebAccess Clustering Worksheet item 1) 
where the WebAccess domain is located. 


The WebAccess Agent volume name will be cluster_volume. For assistance with mapping a 
drive to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 38. 


2 Map a drive to sys:\system on the first node where you want to install the WebAccess 
Application (WebAccess Clustering Worksheet item 10). 


3 Ifthe node where you are going to install the WebAccess Application is currently running any 
applications that rely on Java or on the Netscape Enterprise Server, migrate those applications 
to another node in the cluster. If any GroupWise agents are running on the node, migrate the 
agents. For assistance with migrating resources, see “Migrate Resources” in “Installation and 
Setup” in NetWare Cluster Services Overview and Installation. 


4 Manually stop the Netscape Enterprise Server and unload Java. 
nvxwebdn unload java 


If the WebAccess Installation program detects that the Netscape Enterprise Server and Java 
are still running, it will attempt to stop them for you. However, the Installation program is not 
always successful, so performing this step manually is recommended. 


5 Start the WebAccess Installation program as you did when you installed the WebAccess Agent 
(Step 3 on page 90). Keep in mind the following cluster-specific details: 


+ Inthe Components dialog box, select only GroupWise WebAccess Application. 


+ Use items 13 through 19 on the GroupWise WebAccess Installation Worksheet that you 
filled out during “Planning the WebAccess Installation” on page 87 to fill in the fields 
during the WebAccess Application installation process. 


+ Inthe Gateway Directory dialog box, be sure to browse to the WebAccess gateway 
directory (domain\wpgate\webac60a) through the drive you mapped in Step | above. 


+ Inthe Web Server Information dialog box, be sure to browse to the Web server root 
directory (sys:\novonyx\suitespot) through the drive you mapped in Step 2 above. 


+ Inthe Start Applications dialog box, deselect Restart Web Server. 


6 Make sure you have completed all the WebAccess Application tasks described in “Setting Up 
GroupWise WebAccess on NetWare or Windows” in “Installing GroupWise WebAccess” in 
the GroupWise 6.5 Installation Guide. 


7 Copy the sys:\novonyx\suitespot\docs\com directory from the node where you just installed 
the WebAccess Application to the document root directory of the hardware virtual server 
(WebAccess Clustering Worksheet item 13). 
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8 At the server console, manually restart Java and the Netscape Enterprise Server. 


NetWare 6.x NetWare 5.1 
with Tomcat Servlet Gateway with Novell Servlet Gateway 
tomcat33 nvxwebup load java nvxwebup 


9 In the Cluster State View in ConsoleOne, offline and then online the Netscape Enterprise 
Server cluster resource, as well as any other Web server cluster resources that run on the node 
to reestablish their secondary IP addresses. 


10 Repeat Step 2 through Step 9 for each node in the WebAccess Application failover path 
(WebAccess Clustering Worksheet item 13). 


11 Continue with “Testing Your Clustered WebAccess Installation” on page 96. 


Testing Your Clustered WebAccess Installation 


Remember that the WebAccess Agent volume resource and the Netscape Enterprise Server cluster 
resource are separate resources that could fail over to different nodes at different times. 


To thoroughly test your WebAccess installation: 


1 Make sure the initial combination of WebAccess Agent volume resource and Netscape 
Enterprise Server cluster resource is functioning properly. 


2 Migrate the WebAccess Agent volume resource to each node on its failover path, making sure 
it functions with the initial Netscape Enterprise Server cluster resource. 


3 Migrate the Netscape Enterprise Server cluster resource to a different node, migrate the 
WebAccess Agent volume resource to each node in its failover path, then make sure each 
combination works. 


4 Repeat Step 3 for each Netscape Enterprise Server cluster resource. 


Managing WebAccess in a Cluster 
After you have installed WebAccess in a cluster, you should consider some long-term management 
issues. 
+ “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 96 
+ “Knowing What to Expect in MTA and POA Failover Situations” on page 58 
+ “Updating the WebAccess Agent Configuration File (commegr.cfg)” on page 98 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After installing WebAccess in your clustered GroupWise system, while the cluster-specific 
information is fresh in your mind, you should record that cluster-specific information as part of the 
Group Wise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the 
information recorded in the GroupWise objects if the configuration of your system changes. 


+ “Recording Cluster-Specific Information about the Internet Agent Domain and Its MTA” on 
page 77 


+ “Recording Cluster-Specific Information about the Internet Agent” on page 77 
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Recording Cluster-Specific Information about the WebAccess Agent Domain and Its MTA 


To permanently record important cluster-specific information for the WebAccess Agent domain: 
1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 In the Description field of the WebAccess Agent domain Identification page, provide a 
cluster-specific description of the WebAccess Agent domain, including the secondary IP 
address of its cluster-enabled volume and the cluster-unique port numbers used by its MTA. 


You might also want to include cluster-specific information about the WebAccess 
Application, such as the secondary IP address of the Netscape Enterprise Server cluster 
resource where the WebAccess Application is installed. 


Click OK to save the WebAccess Agent domain description. 
Select the WebAccess Agent Domain object to display its contents. 
Right-click the MTA object, then click Properties. 


aoa bh Ww 


In the Description field of the MTA Identification page, record the secondary IP address of 
the cluster-enabled WebAccess Agent domain volume and the cluster-unique port numbers 
used by the MTA. 


This information will appear on the MTA console, no matter which node in the cluster it is 
currently running on. 


7 Click OK to save the MTA description. 


8 Continue with “Recording Cluster-Specific Information about the Internet Agent” on page 77. 


Recording Cluster-Specific Information about the WebAccess Agent 
With the contents of the WebAccess Agent domain still displayed: 
1 Right-click the WEBAC60A object, then click Properties. 
2 Click GroupWise, then click Identification. 


3 In the Description field, record the secondary IP address of the cluster-enabled WebAccess 
Agent domain volume and the cluster-unique port numbers used by the WebAccess Agent. 


This information will appear on the WebAccess Agent console, no matter which node in the 
cluster it is currently running on. 


4 Click OK to save the WebAccess Agent information. 
5 Continue with “Knowing What to Expect in MTA and POA Failover Situations” on page 58. 


Knowing What to Expect in WebAccess Failover Situations 


The failover behavior of the MTA for the WebAccess Agent domain will be the same as for an 
MTA in a regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” 
on page 58. 


The WebAccess Application caches users’ credentials on the node where it is running. Therefore, 
if that node fails, or if the WebAccess Application migrates to a different node, the cached 
credentials are lost. Consequently, the user will need to restart the WebAccess client in order to re- 
authenticate and re-establish the credentials. 


If the WebAccess Agent fails over or migrates, the user receives an error message that the 
WebAccess Agent is no longer available. However, after the WebAccess Agent starts in its new 
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location, the WebAccess Application passes the cached user credentials to the WebAccess Agent 
and the user reconnects automatically without having to re-authenticate. 


As with the MTA and the POA, migration of the WebAccess Agent takes longer than failover. 
However, the WebAccess Agent restarts quickly so that users are able to reconnect quickly. 


Updating the WebAccess Agent Configuration File (commgr.cfg) 


98 


As part of installing WebAccess, the WebAccess Agent configuration file (commgr.cfg) is created 
in the following subdirectory: 


domain\wpgate\webac60a 
It is also automatically copied to the following Web server subdirectory: 
sys:\novell\webaccess 


If you change WebAccess agent configuration information (for example, if you change its ip 
address), the information is changed in the following file: 


domain\wpgate\webac60a\commer.cfg 
because the domain is on a cluster-enabled volume, and it is changed in the following file: 
sys:\novell\webaccess\commegr.cfg 


on the node where the WebAccess Application is currently running. However, the other nodes on 
the WebAccess Application failover path are not currently available for update. therefore, you 
must manually copy the updated commegr.cfg file to the sys:\novell\webaccess subdirectory on 
each node in the WebAccess Application failover path. 
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WebAccess Clustering Worksheet 


Item 


1) Shared Volume for 
WebAccess Agent: 


Cluster Enabled? 


+ Yes (highly recommended) 


Cluster volume IP address 


+ No 


2) WebAccess Agent 
Domain Name: 


Domain Database Location: 


3) WebAccess Agent 
Failover Path: 


4) MTA Installation Location: 


¢ vol:\system on WebAccess Agent 
volume 


¢ sys:\system on each node 


Consolidate multiple MTA startup 
files on WebAccess Agent volume? 


5) MTA Network Information: 
+ MTA IP address 

+ MTA message transfer port 
+ MTA live remote port 


+ MTA HTTP port 


6) WebAccess Agent 
Installation Location: 


¢ vol:\system on the WebAccess 
Agent volume 


¢ sys:\system on each node 


7) WebAccess Agent 
Network Information: 


+ WebAccess Agent IP address 
+ WebAccess Agent HTTP port 


Explanation 


Specify the name (cluster_volume) of the shared volume where the WebAccess 
Agent domain will be created. 


For cluster-enabling, specify the IP addresses of the virtual server (volume_.cluster) 
to which the cluster-enabled volume is tied. 


For more information, see “Deciding Whether to Cluster-Enable the WebAccess 
Agent Volume” on page 85. 


Specify a unique name for the WebAccess Agent domain. Specify the directory on 
the WebAccess Agent volume where you want to create the new domain. 


For more information, see “Planning a New Domain for the WebAccess Agent” on 
page 85. 


List other nodes in the cluster where the WebAccess Agent and its MTA could fail 
over. 


For more information, see “Determining an Appropriate Failover Path for the 
WebAccess Agent Volume” on page 85. 


Mark the location where you will install the MTA software. 


If necessary, specify the location where you will consolidate multiple MTA startup 
files on a WebAccess Agent volume. 


For more information, see “Deciding Where to Install the WebAccess Agent and Its 
MTA” on page 86. 


Gather the MTA network address information from the WebAccess section of the “IP 
Address Worksheet” on page 34. 


For more information, see “Planning a Secondary IP Address and Cluster-Unique 
Port Numbers for the WebAccess Agent and Its MTA” on page 86. 


Mark the location where you will install the WebAccess Agent software. 


For more information, see “Deciding Where to Install the WebAccess Agent and Its 
MTA” on page 86. 


Gather the WebAccess Agent network address information from the WebAccess 
section of the “IP Address Worksheet” on page 34. 


For more information, see “Planning a Secondary IP Address and Cluster-Unique 
Port Numbers for the WebAccess Agent and Its MTA” on page 86. 
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Item 


8) Load WebAccess Agent and Its MTA 
in Protected Memory? 


+ No 

+ Yes 

Protected address space names: 
+ MTA: 


+ WebAccess: 


9) Physical Web Servers: 


10) Netscape Enterprise Server 
IP Address: 


11) Netscape Enterprise Server Mode: 
+ Active/active (highly recommended) 


+ Active/passive 


12) Netscape Enterprise Server 
Failover Path: 


13) Hardware Virtual Server 
Information: 


+ Dedicated IP address: 


+ Document root 


Explanation 


Mark whether you need to run the WebAccess Agent and its MTA in protected 
memory. If so, specify a unique address space for each agent. 


IMPORTANT: We strongly recommend that you run the WebAccess Agent and its 
MTA in protected memory. 


For more information, see “Deciding Whether to Run the WebAccess Agent and Its 
MTA in Protected Memory” on page 86. 


List the NetWare servers in the cluster where you are installing the Netscape 
Enterprise Server for use with WebAccess. 


For more information, see “Setting Up the Netscape Enterprise Web Server for 
NetWare in a Cluster on NetWare 6” on page 84. 


Record the secondary IP address for the Netscape Enterprise Server cluster 
resource, shown in the cluster resource load script. 


For more information, see “Setting Up the Netscape Enterprise Web Server for 
NetWare in a Cluster on NetWare 6” on page 84. 


Mark whether the Netscape Enterprise Server runs simultaneously on multiple nodes 
in the cluster (active/active) or whether it runs on only one node at a time (active/ 
passive). 


For more information, see “Setting Up the Netscape Enterprise Web Server for 
NetWare in a Cluster on NetWare 6” on page 84. 


List other nodes in the cluster where the Netscape Enterprise Server can fail over. 
The WebAccess Application always fails over along with the Netscape Enterprise 
Server. 


For more information, see “Setting Up the Netscape Enterprise Web Server for 
NetWare in a Cluster on NetWare 6” on page 84. 


Record the hardware virtual server information for your shared disk system. 


For more information, see “Setting Up the Netscape Enterprise Web Server for 
NetWare in a Cluster on NetWare 6” on page 84. 
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WebAccess Quick Checklist 


Q) Plan the new clustered WebAccess installation, including the new domain required to house 


m) 


m) 


the WebAccess Agent in a clustering environment. 
See “Planning WebAccess in a Cluster” on page 83. 
Install and set up the Netscape Enterprise Web Server for NetWare in the cluster. 


See “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” 
on page 84. 


Cluster-enable the volume where the WebAccess Agent domain will reside. 
See “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent” on page 88. 
Create the new WebAccess Agent domain. 
See “Creating a Domain for the WebAccess Agent” on page 89. 
Set up the MTA for the new WebAccess Agent domain. 
See “Installing the MTA for the WebAccess Agent Domain” on page 89. 
Install the WebAccess Agent. 
See “Installing and Configuring the WebAccess Agent in a Cluster” on page 89. 
Modify the WebAccess Agent volume resource load script: 
+ Remove the trustmig command 
+ Add the cvsbind add command (NetWare 5.1 only; optional) 
+ Add the search add command (optional) 


¢ If you will not run the MTA and the WebAccess Agent in protected memory, add the set 
auto restart commands and the set developer option = off command 


+ Add the load commands for the MTA and the WebAccess Agent, separating them with a 
delay command 


+ Ifyou will run the MTA and the WebAccess Agent in protected memory, add the address 
space parameter to the load commands and add a protection restart command for the 
address space 


See “Modifying the Volume Resource Load Script for the WebAccess Agent” on page 90. 
Modify the WebAccess Agent volume resource unload script: 
+ Add the MTA and WebAccess Agent or address space unload command(s) 


+ Add the cvsbind del command if you used the cvsbind add command in the load script 
(NetWare 5.1 only; optional) 


+ Remove the trustmig command 
See “Modifying the Volume Resource Unload Script for the WebAccess Agent” on page 92. 
Set up the WebAccess Agent volume failover path and policies. 
See “Setting the Failover Path and Policies for the WebAccess Agent” on page 94. 


Add the WebAccess Application to each node where the Netscape Enterprise Server is 
installed. 


See “Installing and Configuring the WebAccess Application in a Cluster” on page 95. 
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0 Test the clustered WebAccess Agent. 
See “Testing Your Clustered WebAccess Installation” on page 96. 


QO) Record cluster-specific information in the properties pages of the GroupWise objects 
associated with the WebAccess Agent. 


See “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 96. 
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Implementing GroupWise Gateways in a Novell 
Cluster 


A significant system configuration difference between a GroupWise® system in a clustering 
environment and a Group Wise system in a regular environment is that you need to create a separate 
domain to house each GroupWise gateway. The gateway domain should be created on a cluster- 
enabled volume. This enables the gateway to fail over independently from other GroupWise 
components. 


If you have set up the Internet Agent or WebAccess in your clustered GroupWise system, you 
should already have the skills necessary to set up a GroupWise gateway as well. 


Group Wise gateways that have not received recent development have not been thoroughly tested 
in a clustering environment. If you are currently using such GroupWise gateways, you might want 
to leave them outside of your cluster. 
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Monitoring a GroupWise System in a Novell 
Cluster 


Because the GroupWise® 6.5 Monitor currently runs on Windows NT*/2000, rather than 
NetWare®, you cannot run GroupWise Monitor in a cluster. However, GroupWise Monitor can 
easily monitor a clustered GroupWise system from a vantage point outside the cluster. 


When you first install Monitor, it gathers information about agents to monitor from a domain 
database (wpdomain.db). This provides the secondary IP address of each agent (the IP address 
associated with the cluster-enabled volume where the agent’s domain or post office resides). When 
an agent fails over or migrates to a different node, its status in Monitor displays as Not Listening 
until it is up and running again, at which time its status returns to Normal. 


Because Monitor must use secondary IP addresses to monitor the agents in a clustered GroupWise 
system, the Discover Machine and Discover Network options do not work ina cluster. Secondary 
IP addresses cannot be obtained by examining the network itself. If you need to add agents to 
monitor, use the Add Agent option and provide the agent’s secondary IP address. 


For instructions on setting up GroupWise Monitor, see “Installing GroupWise Monitor” in the 
GroupWise 6.5 Installation Guide. 
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Backing Up a GroupWise System in a Novell 
Cluster with the GroupWise TSA 


The GroupWise” Target Service Agent (GWTSA) is a Group Wise-specific API that works with 
compatible backup software to provide reliable backups of a running GroupWise system. The 
GWTSA can be used in a clustered GroupWise system with appropriate preparation and 
understanding of how the GWTSA works. For background information on the GWTSA and a list 
of compatible backup software, see “GroupWise Target Service Agent ” in “Databases” in the 
GroupWise 6.5 Administration Guide. 


In a clustering environment, the GWTSA must be installed and loaded on each node from which 
your backup software backs up any portion of your GroupWise system. To accommodate the 
variable locations of data to back up from a clustered Group Wise system, the gwtsa.ncf file of each 
node should be edited to include a /home startup switch for every domain and post office on every 
cluster-enabled volume that might ever be mounted on that node. Set the /home startup switch to 
the physical volume name (without the server name), rather than the cluster-enabled volume name, 
when specifying the location of each domain and post office. For example: 


Correct: 
/home-gwvoll:\gwdom 


Incorrect: 
/home-gweluster_gwvoll:\gwdom 


Before your backup software starts backing up your Group Wise system, it calls on the GWTSA to 
verify the accessibility of each physical volume specified by the /home startup switch. Your 
backup software then backs up those domains and post offices that are currently accessible to the 
GWTSA and skips those that are not accessible. The backup runs successfully, even if some 
locations are not currently mounted on the node where the GWTSA is running. Locations skipped 
when backups are run from one node will be caught when backups are run from another node 
where the GWTSA is also running. 


If the node where the GWTSA is running goes down, the backup will need to be rerun when the 
node is up again, unless the nodes where the domain and post office volumes failed over are also 
configured to back them up. There is currently no way to restart a backup from a checkpoint 
position. By configuring redundant backup jobs on all nodes where domains and post offices could 
fail over, you can ensure that domains and post offices are always backed up, regardless of the node 
they are mounted on when the backup takes place. 


WARNING: You should not install the GWTSA on the cluster-enabled volumes where domains and post 
offices are located. The GWTSA cannot currently run in protected memory, nor can it run re-entrantly. If 
multiple GroupWise volumes failed over to the same node, and if that node attempted to start an instance of 
the GWTSA for each GroupWise volume, only the first instance would run successfully. Subsequent instances 
of the GWTSA would fail and the domains and post offices specified for backup by those instances would not 
be available to your backup software. 


To restore data in a clustering environment, you must run your backup/restore software on the node 
where the location to restore is currently mounted. 
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Moving an Existing GroupWise 6.5 System into 
a Novell Cluster 


If you are adding the high availability benefits of Novell® Cluster Services™ to a GroupWise® 6.5 
system that is already up and running, the first step is to install Novell Cluster Services following 
the instructions in NetWare Cluster Services Overview and Installation for your version of 
NetWare®: 


+ NetWare 6.x: “Installation and Setup” 
+ NetWare 5.1: “Installation and Setup” 


You should also review Chapter 1, “Introduction to GroupWise 6.5 and Novell Cluster Services,” 
on page 15 to help you apply clustering principles and practices to your GroupWise system. 


You do not need to transfer your entire GroupWise system into the cluster all at once. You could 
transfer individual post offices where the needs for high availability are greatest. You could 
transfer a domain and all of its post offices at the same time. You might decide that you don’t need 
to have all of your GroupWise system running in the cluster. 


This section provides a checklist to help you get started with moving your Group Wise system into 
a clustering environment: 


Q) Decide which shared volumes in your shared disk system you will use for GroupWise 
administration (ConsoleOne® and the software distribution directory). 


Q) Decide which shared volumes in your shared disk system you will use for Group Wise 
domains and post offices. 


Q Decide which nodes in your storage area network you will have on failover paths for the 
Group Wise agents. 


OQ) Review Chapter 2, “Planning Group Wise in a Novell Cluster,” on page 17. Fill out the 
“System Clustering Worksheet” on page 32 to help you decide which domains and post 
offices you will move to which shared volumes. 


QO) Review “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in 
the Cluster” on page 25 and fill out the “IP Address Worksheet” on page 34 to select 
secondary IP addresses for cluster-enabled volumes and to specify cluster-specific port 
numbers for all of your Group Wise agents. 


Q) Select the first shared volume that will be part of your clustered GroupWise system and 
cluster-enable it, following the instructions in “Cluster-Enabling Shared Volumes for Use with 
GroupWise” on page 37 and “Configuring Short Name Resolution” on page 38. 


QO) Move a domain and/or post office onto the cluster-enabled volume, following the instructions 
in “Moving a Domain” in “Domains” or “Moving a Post Office” in “Post Offices” in the 
GroupWise 6.5 Administration Guide. 
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QO) Review “Deciding How to Install and Configure the Agents in a Cluster” on page 25, fill out 
the “Agent Clustering Worksheet” on page 35, and install the agents as needed for the first 
clustered domain and/or post office, following the instructions in “Installing and Configuring 
the MTA and the POA in a Cluster” on page 44. This includes setting up the load and unload 
scripts for the cluster-enabled volume. 


Q) Test the first component of your clustered GroupWise system following the instructions in 
“Testing Your Clustered GroupWise System” on page 53. 


Q Take care of the cluster management details described in “Managing Your Clustered 
GroupWise System” on page 54. 


Q Move more domains and post offices into the cluster as needed. If you have GroupWise 
libraries, see “Planning a New Library for a Clustered Post Office” on page 21. 


Q Move GroupWise administration into the cluster as needed. 


QO) Add other components to your clustered GroupWise system as needed, following the 
instructions in: 


+ Chapter 4, “Implementing the Internet Agent in a Novell Cluster,” on page 63 

+ Chapter 5, “Implementing WebAccess in a Novell Cluster,” on page 83. 

+ Chapter 6, “Implementing GroupWise Gateways in a Novell Cluster,” on page 103 
+ Chapter 7, “Monitoring a GroupWise System in a Novell Cluster,” on page 105 


+ Chapter 8, “Backing Up a GroupWise System in a Novell Cluster with the Group Wise 
TSA,” on page 107 
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Implementing Messenger in a Novell Cluster 


Novell Messenger does not require the existence of a GroupWise® system in the cluster, but 
presumably one has already been set up as described in Chapter 2, “Planning GroupWise in a 
Novell Cluster,” on page 17 and Chapter 3, “Setting Up a Domain and Post Office in a Novell 
Cluster,” on page 37. As part of the process of setting up GroupWise in the cluster, you filled out 
the “System Clustering Worksheet” on page 32. Some of the information from that worksheet will 
be helpful as you implement Messenger in your cluster. 


+ “Planning Your Messenger System in a Cluster” on page 111 
+ “Setting Up Your Messenger System in a Cluster” on page 114 
+ “Messenger Clustering Worksheet” on page 119 


Planning Your Messenger System in a Cluster 


Because the Messenger agents are not associated with GroupWise domains or post offices, the 
Messenger agents are easier to implement in a cluster than are the GroupWise agents. The 
“Messenger Clustering Worksheet” on page 119 lists all the information you will need as you set 
up the Messenger agents in a clustering environment. You should print the worksheet and fill it out 
as you complete the tasks listed below: 


+ “Understanding Your Cluster” on page 111 
+ “Planning Messenger Administration” on page 111 
+ “Deciding Where to Install the Messenger Agent Software” on page 112 


+ “Planning the Messenger Agent Installation” on page 114 


Understanding Your Cluster 


Fill out items 1 through 5 on the “Messenger Clustering Worksheet” on page 119 with information 
about your cluster. This information corresponds to items 1-5 on the “System Clustering 
Worksheet” on page 32. For background information, see “Meeting Software Version 
Requirements” on page 18 and “Installing Novell Cluster Services” on page 19. 


Planning Messenger Administration 


If you have set up a cluster-enabled shared volume for GroupWise administration, as described in 
“Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise” on page 21, you 
can use the same cluster-enabled shared volume for the Messenger administration files. For 
example, you might have a shared pub: volume with a \public directory where you install the 
Messenger snap-in to ConsoleOne®. Or you can install the Messenger snap-in on one or more 
administrator workstations. 
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MESSENGER CLUSTERING WORKSHEET 


Under Item 6: Installation Location for Messenger Administration, mark where you want to install the 
Messenger snap-in to ConsoleOne. 


If you plan to install the Messenger snap-in to ConsoleOne on a cluster-enabled shared volume, under 
Item 7: Shared Volume for Messenger Administration, list the IP address of the shared volume and 
the directory where you want to install the Messenger snap-in. 


IMPORTANT: Cluster-enabling relies on successful short name resolution throughout your system. 
Review “Ensuring Successful Name Resolution for GroupWise Volumes” on page 23, which describes 
the issues in the context of planning MTA and POA installations for GroupWise. 


Deciding Where to Install the Messenger Agent Software 


When you install the NetWare® Messenger agents in a clustering environment, you can choose 
between two different installation locations: 


Location Description 

Each node The sys:\system directory is the default location provided by the Messenger 
in the cluster Installation program. 

Shared volume If you create a vol:\system directory on a cluster-enabled shared volume, the 


agent software and startup files fail over and back along with supporting files 
such as the Messenger archive. 


IMPORTANT: Cluster-enabling relies on successful short name resolution 
throughout your system. Review “Ensuring Successful Name Resolution for 
GroupWise Volumes” on page 23, which describes the issues in the context of 
planning MTA and POA installations for GroupWise. 


You must install to a cluster-enabled shared volume if you do not want a separate Messenger 
archive to be created on each node where the Archive Agent runs. If you do not want to use a 
shared volume, you should plan to install the Archive Agent separately outside the cluster. 


MESSENGER CLUSTERING WORKSHEET 
Under Item 8: Installation Location for Messenger Agents, mark where you want to install the 


Messenger agent software. 


Continue with the planning instructions for the installation location you want to use: 
¢ “Each Node in the Cluster” on page 112 
+ “Shared Volume” on page 113 
Each Node in the Cluster 


Make sure you have filled out item 5 on the Messenger Clustering Worksheet with a complete list 
of nodes in the cluster. Continue with “Planning the Messenger Agent Installation” on page 114. 


112 GroupWise 6.5 Interoperability Guide 


Shared Volume 


For convenience throughout the rest of this section, the term "Messenger volume" means "a 
cluster-enabled shared volume where the Messenger agents are installed." Complete the following 
planning tasks for the Massager volume: 


¢ “Selecting the Messenger Volume” on page 113 
+ “Determining an Appropriate Failover Path for the Messenger Volume” on page 113 


¢ “Selecting IP Address Resolution Methods for the Messenger Volume” on page 113 


Selecting the Messenger Volume 


If you are not planning to enable archiving, or if you are not anticipating a large Messenger 
archive, you can use one Messenger volume. If you anticipate archiving a large number of 
messages so that the Messenger archive grows very large, you might want to have a separate 
Messenger volume for the Archive Agent and the archive database. The steps in this section cover 
setting up the Messenger agents on a single Messenger volume. 


MESSENGER CLUSTERING WORKSHEET 


Under Item 9: Shared Volume for Messenger Agents, record the name and IP address of the 
Messenger volume. 


Determining an Appropriate Failover Path for the Messenger Volume 


By default, a Messenger volume is configured to have all nodes in the cluster in its failover path, 
organized in ascending alphanumeric order. Only one node at a time can have the Messenger 
volume mounted and active. If a Messenger volume’s preferred node fails, the volume fails over 
to the next node in the failover path. 


MESSENGER CLUSTERING WORKSHEET 


Under Item 10: Failover Path for Messenger Volume, list the nodes that you want to have in the 
Messenger volume failover path. The Messenger agents might need to run on any node that the 
Messenger volume fails over to. 


Selecting IP Address Resolution Methods for the Messenger Volume 


Because you are using a cluster-enabled volume for the Messenger agents, you must ensure that 
short name resolution is always successful. For background information, see “Ensuring Successful 
Name Resolution for GroupWise Volumes” on page 23. 


MESSENGER CLUSTERING WORKSHEET 


Under Item 11: IP Address Resolution Methods, mark the short name address resolution methods you 
want to implement to ensure that the UNC paths stored in ConsoleOne can be successfully resolved 
into the physical network address of the Messenger volume. 
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Planning the Messenger Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Messenger agents are the same in a clustering environment as 
for any other environment. Review “Planning Your Novell Messenger System”, then print and fill 
out the “Novell Messenger System Worksheet” in “Installing a Novell Messenger System” in the 
Messenger 1.0 Installation Guide. Transfer the following information from the Messenger 
Clustering Worksheet to the Messenger System Worksheet: 


¢ For Item 3: Installation Path on the Messenger System Worksheet: 
¢ If you are installing the Messenger agents to each node in the cluster, use sys:\system. 


¢ If you are installing the Messenger agents to a Messenger volume, use volume:\system, 
where volume is the name of the Messenger volume from Item 9: Shared Volume for 
Messenger Administration on the Messenger Clustering Worksheet. 


+ Under Item 12: Server Address on the Messenger System Worksheet: 


¢ If you are installing the Messenger agents to each node in the cluster, use the cluster IP 
address from Item 3: Cluster Identification on the Messenger Clustering Worksheet. 


¢ Ifyou are installing the Messenger agents to a Messenger volume, specify the Messenger 
volume IP address from Item 9: Shared Volume for Messenger Agents on the Messenger 
Clustering Worksheet. 


+ Under Item 13: Configure Agents for Clustering? on the Messenger System Worksheet, mark 
Yes. This adds the /cluster switch to the agent startup files. The /cluster switch tells the 
Messenger agents to use the virtual server name of the cluster or the Messenger volume rather 
than the specific server name in pathnames obtained from agent object properties in Novell® 
eDirectory™ or from startup switches.This enables the Messenger agents to access the 
location no matter which node it is currently running on. This applies to the agents’ working 
directory, queue directory, log file directory, and so on. 


+ Under Item 14: Admin Configuration on the Messenger System Worksheet: 


¢ If you are installing the Messenger snap-in to ConsoleOne to an administrator 
workstation, use the location where ConsoleOne is already installed (typically 
c:\novell\consoleone\version_number). 


¢ If you are installing the Messenger snap-in to ConsoleOne to a shared volume, use 
volume:\directory, where volume is the name of the Messenger administration volume 
from Item 7: Shared Volume for Messenger Administration on the Messenger Clustering 
Worksheet and directory is typically \public. 


Continue with “Setting Up Your Messenger System in a Cluster” on page 114. 
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You should have already reviewed “Planning Your Messenger System in a Cluster” on page 111 
and filled out the “Messenger Clustering Worksheet” on page 119 and the “Novell Messenger 
System Worksheet” in the Messenger 1.0 Installation Guide. Follow the instructions for the 
installation location you have chosen: 


+ “Installing to Each Node in the Cluster” on page 115 


+ “Installing to a Messenger Volume” on page 115 
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Installing to Each Node in the Cluster 


There are two methods of installing the Messenger agents to each node in the cluster: 


+ 


+ 


Run the Messenger Installation program multiple times in order to install the agent software 
and to create the agent startup files on each node in the cluster. 


Run the Messenger Installation program, then copy the Messenger agent software and startup 
files to each node in the cluster. 


Use whichever method you prefer, following the steps provided in “Starting the Messenger 
Installation Program” and “Creating Your Messenger System” in “Installing a Novell Messenger 
System” in the Messenger 1.0 Installation Guide. Make each node in the cluster active to make 
sure that the Messenger agents start successfully. 


Installing to a Messenger Volume 


Complete the following tasks to set up your Messenger system on a Messenger volume: 


+ 


+ 


+ 


“Preparing the Cluster for Messenger” on page 115 
“Running the Messenger Installation Program” on page 115 


“Configuring the Messenger Volume Resource to Load and Unload the Messenger Agents” 
on page 116 


“Copying LDAP and QuickFinder Files to Each Node” on page 117 
“Testing Your Clustered Messenger System” on page 117 


Preparing the Cluster for Messenger 


Cluster preparation for Messenger is the same as cluster preparation for GroupWise. Review 
“Preparing the Cluster for GroupWise” on page 37 before running the Messenger installation 
program. 


Running the Messenger Installation Program 


The Messenger Installation program walks you through setting up your Messenger system and 
installing the Messenger agents. 


1 


2 


If necessary, map a drive to the Messenger administration volume (Messenger Clustering 
Worksheet item 7). 


Map a drive to the Messenger volume (Messenger Clustering Worksheet item 9). 


The Messenger volume name will be cluster _volume. For assistance with mapping a drive to 
a cluster-enabled volume, see “Configuring Short Name Resolution” on page 38. 


Run the Messenger Installation program at an administrator workstation to set up your 
Messenger system, following the steps provided in “Starting the Messenger Installation 
Program” and “Creating Your Messenger System” in “Installing a Novell Messenger System” 
in the Messenger 1.0 Installation Guide. Keep in mind the following cluster-specific details: 


+ When you specify the Messenger installation directory, be sure to browse to the location 
through the Messenger volume accessed in Step 2 above. 


+ When you specify the ConsoleOne directory, be sure to browse to the location through 
the Messenger administration volume accessed in Step | above. 
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+  Onthe Start Copying Files page, the server object name should be the virtual server name, 
not a physical server name. 


4 When you have finished creating your Messenger system, continue with “Configuring the 
Messenger Volume Resource to Load and Unload the Messenger Agents” on page 116. 


Configuring the Messenger Volume Resource to Load and Unload the Messenger Agents 


The properties of the Volume Resource object define how the Messenger volume functions within 
the cluster, how the Messenger agents are loaded and unloaded, and how failover and failback 
situations are handled. 


1 In ConsoleOne, browse to and select the Cluster object. 
If necessary, click View > Console View to display its contents. 


2 Right-click the Volume Resource object (volume SERVER), then click Properties > Load to 
display the default volume resource load script for the Messenger volume. 


The volume resource load script executes whenever the Messenger volume comes online. 
3 Add the following lines to the load script: 


load volume: \novell\nm\ma\nmma.nlm @volume:novel\nm\ma\strtup.ma 
load volume: \novell\nm\aa\nmaa.nlm @volume:novel\nm\aa\strtup.aa 


where volume is the name of the Messenger volume (Messenger Clustering Worksheet item 
9). 


For example: 


load gwmsgr:\novell\nm\ma\nmma.nlm @gwmsgr:novel\nm\ma\strtup.ma 
load gwmsg:\novell\nm\aa\nmaa.nlm @gwmsgr:novel\nm\aa\strtup.aa 


4 Click apply to save the load script. 
5 Click Unload. 
6 Add the following lines to the unload script: 


unload nmma.nlm 
unload nmaa.nlm 


7 Click Apply to save the unload script. 
8 Click Nodes to display the default failover path for the Messenger volume. 


9 Arrange the nodes in the cluster into the desired failover path for the Messenger volume 
(Messenger Clustering Worksheet item 10). 


10 Click Apply to save the failover path. 

11 Click Policies to display the default start, failover, and failback policies. 
By default, a volume resource: 
+ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the net node in its failover path 


+ Continues running at its failover location even after its most preferred node is again 
available 


42 Change the policies if necessary, then click OK. 
13 Continue with “Copying LDAP and QuickFinder Files to Each Node” on page 117. 
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Copying LDAP and QuickFinder Files to Each Node 


During installation of the Messenger agents, some files were copied to sys:\system of the node 
where the Messenger volume was mounted. These files must be copied to sys:\system on each 
node of the cluster. Copy the following files from the Novell GroupWise Messenger CD to 
sys:\system on each node in the cluster: 


\server\nIm\Idap\ldapsdk.nlm 
\server\nlm\Idap\Idapssl.nlm 
\server\nlm\ldap\ldapx.nlm 
\server\nlm\qf\qfind215.nlm 


If you are running in a language other than English, copy the following files from the CD to 
sys:\system\nls\language on each node in the cluster: 


\server\nlm\/anguage\* msg 
\server\nlm\/anguage\* .hlp 


where language is a two-letter language code. 


Continue with “Testing Your Clustered Messenger System” on page 117. 


Testing Your Clustered Messenger System 


After you have configured the Messenger volume resource, you can test the load and unload scripts 
by bringing the Messenger volume online and taking it offline again. 


1 In ConsoleOne, select the Cluster object, then click View > Cluster State. 


Cluster State | Event Log | HTML Report] 
p gw-cluster Epoch 1 Connected 


GW-CLUSTER1 GW-CLUSTER2 


Nodes Available (%) Resources Available (%) ~; 
0 20 40 60 80 100 0 20 40 60 80 100 


Cluster Resource State Location #Lives | 
@ GWVOL_SERVER | Offline GW-CLUSTER1 2 | 
@ ILVOL_SERVER Running GW-CLUSTER1 2 | 


The new Messenger volume resource shows Offline in the State column. 


2 Click the new Messenger volume resource, then click Online. 


Cluster State | Event Log | HTML Report| 
p gw-cluster Epoch 1 Connected 


GW-CLUSTER1 GW-CLUSTER2 


Nodes Available (%) Resources Available ($) 
0 20 40 60 80 100 0 20 40 60 80 100 


Cluster Resource State Location 


@ GWVOL_SERVER | Running GW-CLUSTER1 
@ ILVOL_SERVER Running GW-CLUSTER1 
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The State column for the volume resource now displays Running. 


3 Observe the server console where the Messenger agents are loading to see that they start and 
run correctly. 


4 Click the new Messenger volume resource, then click Offline. 
The State column for the volume resource returns to Offline. 


5 Observe the server console where the Messenger agents are unloading to see that they shut 
down correctly. 


6 Repeat Step 2 whenever you are ready to bring the new Messenger volume resource online 
permanently. 


On NetWare 6.x, these actions can also be performed from your Web browser. See “Using 
NetWare Remote Manager on NetWare 6.x” on page 55. 
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Messenger Clustering Worksheet 


Item 


1) Software Version Updates 
for Cluster: 


+ Support Pack 3 or higher for NetWare 5.1 


+ Latest ConsoleOne Snap-In for Novell 
Cluster Services™ 


2) eDirectory Tree for Cluster: 


3) Cluster Identification: 
Cluster Name: 


Cluster IP Address: 


4) Cluster Context: 


5) Nodes in Cluster 


6) Installation Location for Messenger 
Administration: 


+ Administrator workstation(s) 


+ Shared volume 


7) Shared Volume for Messenger 
Administration: 


Cluster Volume IP Address: 


Installation Location for Messenger Snap-In to 
ConsoleOne: 


¢ /public directory 
+ Other directory 


8) Installation Location for Messenger Agents: 
+ Each node in the cluster 


+ Shared volume 


Explanation 


Mark any updates that the nodes in your cluster need in order to meet the 
system requirements for Messenger system in a cluster. 


To review the background information provided for GroupWise clustering, 
see “Meeting Software Version Requirements” on page 18. 


Record the eDirectory tree where you created the Novell Cluster object 
when you installed Novell Cluster Services. 


To review the background information provided for GroupWise clustering, 
see “Installing Novell Cluster Services” on page 19. 


Record the name of the name of the NetWare Cluster object where your 
Messenger system will be located. Also record the virtual IP address of the 
cluster that will remain constant regardless of which node is currently active. 


To review the background information provided for GroupWise clustering, 
see “Installing Novell Cluster Services” on page 19. 


Record the full context where you created the NetWare Cluster object. 


To review the background information provided for GroupWise clustering, 
see “Installing Novell Cluster Services” on page 19. 


List the nodes that are part of the cluster. 


To review the background information provided for GroupWise clustering, 
see “Installing Novell Cluster Services” on page 19. 


Mark the location where you will install the Messenger snap-in to 
ConsoleOne. For more information, see “Planning Messenger 
Administration” on page 111. 


If you plan to install the Messenger snap-in to ConsoleOne on a shared 
volume, specify the name (cluster_volume) of the shared volume where you 
will install it. 


Specify the IP addresses of the virtual server (volume_SERVER.cluster) to 
which the shared volume is tied. 


Specify the directory where you will install the Messenger snap-in to 
ConsoleOne on the shared volume. 


To review the background information about cluster-enabled volumes 
provided for GroupWise, see “Deciding Whether to Cluster-Enable the 
Shared Volumes Used by GroupWise” on page 21. 


Mark the location where you will install the Messaging Agent software. 


For more information, see “Deciding Where to Install the Messenger Agent 
Software” on page 112. 
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Item 


9) Shared Volume for Messenger Agents: 


Cluster volume IP address: 


10) Failover Path for Messenger Shared 
Volume: 


11) IP Address Resolution Methods: 
+ eDirectory 

+ hosts file 

« DNS 

+ SLP (highly recommended) 
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Explanation 


If you plan to install the Messenger agents on a shared volume, specify the 
name (cluster_volume) of the shared volume. 


Specify the IP address of the virtual server (volume_SERVER.cluster) to 
which the cluster-enabled volume is tied. 


To review the background information about cluster-enabled volumes 
provided for GroupWise, see “Deciding Whether to Cluster-Enable the 
Shared Volumes Used by GroupWise” on page 21. 


For more information, see “Selecting the Messenger Volume” on page 113. 


If you plan to install the Messenger agents on a shared volume, list other 
nodes in the cluster where the Messenger agents could fail over. 


For more information, see “Determining an Appropriate Failover Path for the 
Messenger Volume” on page 113. 


Mark the short name address resolution methods you want to implement to 
ensure that the UNC paths stored in ConsoleOne can be successfully 
resolved into physical network addresses. 


To review the background information provided for GroupWise, see 
“Ensuring Successful Name Resolution for GroupWise Volumes” on 
page 23. 


GroupWise DirXML Driver for Novell Identity 
Manager 


The GroupWise” DirXML® driver for use with Novell® Identity Manager provides data 
integration between users in Novell eDirectory™ with GroupWise accounts in your GroupWise 
system. For example, the driver can create e-mail accounts automatically when employees are 
hired. The driver can also disable an e-mail account when a user is no longer active. This 
configurable solution gives your the ability to increase productivity and streamline business 
processes by integrating GroupWise and eDirectory. 


This guide gives information about certain administrative actions in ConsoleOne® that require you 
to stop the GroupWise DirXML driver or disable a user’s association: 


+ Chapter 11, “Identity Manager Warnings in ConsoleOne,” on page 123 
For additional information, see: 
+ Novell Identity Manager (http://www.novell.com/documentation/dirxml20) 


¢ Identity Manager Drivers (http://www.novell.com/documentation/dirxmldrivers) 
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Identity Manager Warnings in ConsoleOne 


Some GroupWise administrative actions in ConsoleOne require that you stop the GroupWise 
DirXML driver or disable a user’s association with it before you perform the action and usually 
restart the GroupWise DirXML driver or re-enable the user’s association when you have 
completed the action. By default, these activities generate a warning message in ConsoleOne: 


+ 


+ 


+ 


+ 


“Recovering a Deleted GroupWise Account” on page 123 

“Grafting Users” on page 123 

“Converting an External Entity to a User” on page 124 

“Converting a User to an External Entity” on page 124 

“Associating a GroupWise Object with an eDirectory Object” on page 124 
“Disassociating a GroupWise Object’s Attributes from an eDirectory Object” on page 124 
“Resolving an Invalid Association” on page 124 

“Disabling the DirXML Warnings” on page 124 

“Enabling the DirXML Warnings” on page 125 


Recovering a Deleted GroupWise Account 


1 


2 


3 


Grafting Users 


1 


2 


Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML 
driver. 


Recover the deleted account, as described in “Recovering Deleted GroupWise Accounts” in 
“Databases” in the Group Wise 6.5 Administration Guide. 


Using the DirXML Management role, restart the GroupWise DirXML driver. 


If you are grafting the users into a different eDirectory tree, on the DirXML tab of each User 
object in Novell iManager, disable the association with the GroupWise DirXML driver. 


Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML 
driver for the tree into which you are grafting the users. 


Graft the users, as described in “Graft GroupWise Objects” in “Databases” in the GroupWise 
6.5 Administration Guide. 


If you grafted the users into a different eDirectory tree, on the DirXML tab of each User 
object, enable the association with the GroupWise DirXML driver in the new tree. 


Using the DirXML Management role, restart the GroupWise DirXML driver for the tree into 
which you grafted the users. 
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Converting an External Entity to a User 
1 Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML 
driver. 


2 Convert the external entity, as described in “Convert External Entity to User” in “System” in 
the GroupWise 6.5 Administration Guide. 


3 Using the DirXML Management role, restart the GroupWise DirXML driver. 


Converting a User to an External Entity 
1 On the DirXML tab of the User object in Novell iManager, disable the association with the 
GroupWise DirXML driver. 


2 Convert the user, as described in “Convert User to External Entity” in “System” in the 
GroupWise 6.5 Administration Guide. 


Associating a GroupWise Object with an eDirectory Object 
1 Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML 
driver. 


2 Establish the association, as described in “Associate Objects” in “System” in the GroupWise 
6.5 Administration Guide. 


3 Using the DirXML Management role, restart the GroupWise DirXML driver. 


Disassociating a GroupWise Object’s Attributes from an eDirectory 
Object 


1 On the DirXML tab of the User object in Novell iManager, disable the association with the 
GroupWise DirXML driver. 


2 Disassociate the objects, as described in “Disassociate GroupWise Attributes” in “System” in 
the GroupWise 6.5 Administration Guide. 


3 On the DirXML tab of the User object, enable the association with the GroupWise DirXx ML 
driver. 


Resolving an Invalid Association 


1 On the DirXML tab of the User object in Novell iManager, disable the association with the 
GroupWise DirXML driver. 


2 Resolve the invalid association, as described in “Invalid Associations” in “System” in the 
GroupWise 6.5 Administration Guide. 


Disabling the DirXML Warnings 


1 In ConsoleOne, deselect Display DirXML Warnings in any DirXML warning dialog box. 


124 GroupWise 6.5 Interoperability Guide 


Enabling the DirXML Warnings 


1 In ConsoleOne, click Tools > GroupWise System Operations > System Preferences. 
2 On the Admin Preferences tab, select Display DirXML Warnings. 
3 Click OK. 
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GroupWise Customization Tools 


The GroupWise” Software Developer Kit provides tools for customizing GroupWise to the 
specific needs of your organization. It includes the following components: 


+ WebAccess Customization: Lets you modify the WebAccess client HTML source files to 
include your own graphics or company information. You can also enhance the WebAccess 
client by creating additional calendar views. For more information, see Group Wise 
WebAccess Customization (http://developer.novell.com/ndk/gwwbacc.htm). 


+ GroupWise Object API: Lets you create your own client application. It provides access to 
the Address Book, along with documents, mail messages, appointments, tasks, notes, phone 
messages, and workflow items. GroupWise Object API supports COM Automation, which is 
an industry standard for interfacing applications and is simple to use with languages such as 
Delphi*, Visual Basic*, and C++. For more information, see GroupWise Object API (http:// 
developer.novell.com/ndk/gwobjapi.htm). 


+ GroupWise Administrative Object API: Lets you see, use, and manipulate Group Wise 
administration information from outside GroupWise. You can use GroupWise Administrative 
Object API through COM languages, such as Visual Basic, Delphi, and object-oriented 
languages (such as C++). It also supports COM Automation, which is an industry standard for 
interfacing applications. For more information, see GroupWise Administrative Object API 
(http://developer.novell.com/ndk/gwadmin.htm). 


+ GroupWise C3PO: Works with C++, Delphi, or Visual Basic to let you add menu and toolbar 
items to trigger applications. For example, you can modify the GroupWise client toolbar or 
define new record types in the GroupWise information store. C3PO™ stands for Custom 3rd- 
Party Object™. For more information, see GroupWise C3PO (http://developer.novell.com/ 
ndk/gwe3po.htm). 


+ GroupWise Tokens: Let you manipulate the GroupWise client interface by subscribing to 
internal token events or by publishing new tokens to the client. It names low-level events, such 
as "save a file" or "send mail," which allows you to extend GroupWise functionality. While a 
C3PO lets you extend Group Wise objects and the Object API lets you see and manipulate the 
Group Wise information store from outside GroupWise, tokens let your solution command the 
Group Wise client from DLLs and DDE scripts, using the Third-Party Handler. You can also 
use tokens to create Visual Basic executables that users can run from the client interface. For 
more information, see GroupWise Tokens (http://developer.novell.com/ndk/gwtoken.htm). 


+ GroupWise MAPI: Uses a set of object-oriented functions that provide messaging 
capabilities. Messaging Application Programming Interface (MAPI) is used by mail-enabled 
applications to create, transfer, and store messages, as well as to handle complex addressing 
information. MAPI objects are data structures that support a set of properties and that comply 
with the component object model (which requires that objects support one or more interfaces 
or sets of functions). For more information, see GroupWise MAPI (http:// 
developer.novell.com/ndk/gwmapi.htm). 
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+ GroupWise Controls for ActiveX: Lets you embed an Address Book or Name Completion 
COM Control (OCX) in your Visual Basic, Delphi, and C++ solutions. OCX properties let 
you customize user access to Address Book contents and control return information for your 
solution to use. For more information, see GroupWise Controls for ActiveX (http:// 
developer.novell.com/ndk/gwactive.htm). 
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Microsoft Clustering Services 


Chapter 12, “Introduction to GroupWise 6.5 and Microsoft Clusters,” on page 131 

Chapter 13, “Planning GroupWise in a Microsoft Cluster,” on page 133 

Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149 
Chapter 15, “Implementing the Internet Agent in a Microsoft Cluster,” on page 161 

Chapter 16, “Implementing WebAccess in a Microsoft Cluster,” on page 171 

Chapter 17, “Implementing GroupWise Gateways in a Microsoft Cluster,” on page 183 

Chapter 18, “Monitoring a GroupWise System in a Microsoft Cluster,” on page 185 

Chapter 19, “Backing Up a GroupWise System in a Microsoft Cluster,” on page 187 

Chapter 20, “Moving an Existing GroupWise 6.5 System into a Microsoft Cluster,” on page 189 
Chapter 21, “Implementing Messenger in a Microsoft Cluster,” on page 191 
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Introduction to GroupWise 6.5 and Microsoft 
Clusters 


Before implementing GroupWise” 6.5 in a Microsoft* cluster, make sure you have a solid 
understanding of Microsoft clustering technologies by reviewing the following information 
resources: 


+ Cluster Technologies Community Center (http://www.microsoft.com/windowsserver2003/ 
community/centers/clustering/more_resources.asp) 


+ Windows* 2003 Clustering Services (http://www.microsoft.com/windowsserver2003/ 
technologies/clustering/default.mspx) 


+ Windows 2000 Clustering Technologies (http://www.microsoft.com/windows2000/ 
technologies/clustering/default.asp) 


When you review the information resources recommended above, you discover that clustering 
employs very specialized terminology. The following brief glossary provides basic definitions of 
clustering terms and relates them to your GroupWise system: 


cluster: A grouping of from two to eight Windows servers configured so that data storage 
locations and applications can transfer from one server to another without interrupting their 
availability to users. 


node: A clustered server; in other words, a single Windows server that is part of a cluster. 


active node: A node in the cluster that is actively running programs. An active node makes its 
resources available in the cluster. 


passive node: A node in the cluster that is not currently running programs, but is waiting for an 
active node to fail. A passive node does not make its resources available in the cluster until an 
active node fails over to it. 


resource: A data storage location or application. For example, a domain directory and the MTA 
for the domain are resources. A post office directory and the POA for the post office are resources. 


resource group: Two or more resources that must fail over together in order to remain functional. 
For example, for a domain to be functional, the domain directory and its MTA must fail over 
together. For a post office to be functional, the post office directory and its POA must fail over 
together 


physical disk: The physical location where resources are created or installed. For example, a 
domain or post office directory is created on a physical disk. The agent software is installed on a 
physical disk. 


shared disk: A physical disk that can be made active on any node in the cluster. 


failover: The process of moving resources and resource groups on a shared disk from a failed node 
to a functional node so that availability to users is uninterrupted. For example, if the node where 
the POA is running goes down, the post office resource group would fail over to another node so 
that users could continue to use GroupWise. 
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fan-out-failover: The configuration where resources and resource groups from a failed node fail 
over to different nodes in order to distribute the load from the failed node across multiple nodes in 
the cluster. For example, if a node runs a resource group consisting of a domain and its MTA, 
another resource group consisting of a post office and its POA, and a third resource group for 
WebAccess, each resource group could be configured to fail over separately to different nodes in 
the cluster. 


failback: The process of returning resources and resource groups to their original node after the 
situation causing the failover has been resolved. For example, if a POA and its post office fail over 
to another node in the cluster, that resource group can be configured to fail back to its original node 
when the problem is resolved. 


shared disk system: The hardware housing the physical disks that are shared among the nodes in 
the cluster. The C: drives in the clustered nodes are not part of the shared disk system. Each C: 
drive belongs to its own server. 


storage area network (SAN): The clustered nodes together with their shared disk system and 
shared physical disks. 
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Planning GroupWise in a Microsoft Cluster 


The majority of this guide (Chapter 13, “Planning Group Wise in a Microsoft Cluster,” on page 133 
through Chapter 19, “Backing Up a GroupWise System in a Microsoft Cluster,” on page 187) is 

designed for those who are creating a new GroupWise® system, or at least new domains and post 
offices, in a Microsoft cluster. If you already have an existing Group Wise 6.x system and need to 
configure it to work in a newly installed cluster, see Chapter 20, “Moving an Existing Group Wise 
6.5 System into a Microsoft Cluster,” on page 189. 


When you implement a new GroupWise system or a new domain or post office in a Microsoft 
cluster, overall Group Wise system design does not need to change substantially. For a review, see 
“Installing a Basic GroupWise System” in the GroupWise 6.5 Installation Guide. However, the 
configuration of individual components of your GroupWise system will be significantly different. 
This section helps you plan the following GroupWise components in a Microsoft cluster: 


+ A new GroupWise system consisting of the primary domain and the initial post office 
+ A new secondary domain 
+ A new post office 


+ The GroupWise agents (MTA and POA) 


During the planning process, component configuration alternatives will be explained. For 
example, you might want the domain and post office together in the same resource group or in 
separate resource groups. You might want to install the agents to the standard c:\grpwise directory 
on each node or to manually create a drive:\grpwise directory for each shared disk for domains and 
post offices so that the agents fail over with the domains and post offices they service. 


The “System Clustering Worksheet” on page 144 lists all the information you will need as you set 
up GroupWise in a Microsoft cluster. You should print the worksheet and fill it out as you complete 
the tasks listed below: 


¢ “Setting Up Your Microsoft Cluster” on page 134 

+ “Planning a New Clustered Domain” on page 134 

¢ “Planning a New Clustered Post Office” on page 135 

+ “Planning a Library for a New Clustered Post Office” on page 135 

+ “Planning GroupWise Resource Groups” on page 136 

+ “Planning Shared Administrative Resources” on page 137 

+ “Ensuring Successful Name Resolution for GroupWise Resource Groups” on page 137 
¢ “Deciding How to Install and Configure the Agents in a Cluster” on page 139 


+ “GroupWise Clustering Worksheets” on page 144 


After you have completed the tasks and filled out the “System Clustering Worksheet” on page 144, 
you will be ready to continue with Chapter 14, “Setting Up a Domain and Post Office in a 
Microsoft Cluster,” on page 149. 
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Setting Up Your Microsoft Cluster 


As you set up your Microsoft cluster, record key information about the cluster on the System 
Clustering Worksheet: 


SYSTEM CLUSTERING WORKSHEET 


Under Item 1: Cluster Name, record the name of your Microsoft cluster. 


Under Item 2: Nodes in Cluster, list the servers that you have added to the cluster. 


The number of nodes in the cluster will strongly influence where you place GroupWise domains 
and post offices. You have several alternatives: 


+ Your whole GroupWise system can run in a single cluster. 


¢ Parts of your GroupWise system can run in one cluster while other parts of it run in one or 
more other clusters. 


¢ Parts of your GroupWise system can run in a cluster while other parts run outside of the 
cluster, on non-clustered servers. 


If you do not have the system resources to run all of your GroupWise system in the cluster, you 
must decide which parts have the most urgent need for the high availability provided by clustering. 
Here are some suggestions: 


+ Post offices and their POAs must be available in order for users to access their GroupWise 
mailboxes. Therefore, post offices and their POAs are excellent candidates for the high 
availability provided in a cluster. 


+ Ina like manner, WebAccess provides user access to GroupWise mailboxes across the Internet 
through users’ Web browsers. It is another good candidate for the cluster. 


+ Domains and their MTAs are less noticeable to GroupWise client users when they are 
unavailable (unless users in different post offices happen to be actively engaged in an e-mail 
discussion when the MTA goes down). On the other hand, domains and their MTAs are critical 
to Group Wise administrators, although administrators might be more tolerant of a down 
server than client users are. Critical domains in your GroupWise system are the primary 
domain and, if you have one, a hub or routing domain. These domains should be in the cluster, 
even if other domains are not. 


+ The Internet Agent might or might not require high availability in your GroupWise system, 
depending on the importance of immediate messaging across the Internet and the use of POP3 
or IMAP4 clients by GroupWise users. 


There is no right or wrong way to implement Group Wise in a cluster. It all depends on the specific 
needs of your particular GroupWise system and its users. 


Planning a New Clustered Domain 


The considerations involved in planning a new domain in a Microsoft cluster are essentially the 
same as for any other environment. 


¢ Primary Domain: If you are setting up a new GroupWise system in a Microsoft cluster, you 
will be creating the primary domain as you complete the tasks in this section. In preparation, 
review “Planning Your Basic GroupWise System”, then print and fill out the “Basic 
GroupWise System Worksheet” in “Installing a Basic GroupWise System” in the GroupWise 
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6.5 Installation Guide. This covers planning the primary domain and an initial post office in 
the primary domain. 


¢ Secondary Domain: If your GroupWise system already exists, you will be creating a new 
secondary domain. In preparation, review “Planning a New Domain”, then print and fill out 
the “Domain Worksheet” in “Domains” in the GroupWise 6.5 Administration Guide. 


Regardless of the type of domain you are creating, keep in mind the following cluster-specific 
details as you fill out the worksheet you need: 


+ When you specify the location for the domain directory (and for a new GroupWise system, 
the post office directory) on the worksheet, include the shared disk where you want the 
directory to reside. 


+ Do not concern yourself with the GroupWise agent information on the worksheet. You will 
plan the agent installation later. If you are filling out the Basic Group Wise System Worksheet, 
stop with item 17. If you are filling out the Domain Worksheet, stop with item 10. 


When you have completed the worksheet, transfer the key information from the Basic Group Wise 
System Worksheet or the Domain Worksheet to the System Clustering Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 7: Domain Name, transfer the domain name and directory to the System Clustering 
Worksheet. 


IMPORTANT: Do not create the new domain until you are instructed to do so in Chapter 3, “Setting Up a 
Domain and Post Office in a Novell Cluster,” on page 37. 


Planning a New Clustered Post Office 


The considerations involved in planning a new post office in a Microsoft cluster are essentially the 
same as for any other environment. The initial post office in a new GroupWise system is planned 
on the Basic Group Wise System Worksheet. To plan additional new post offices, review “Planning 
a New Post Office ”, then print and fill out the “Post Office Worksheet” in “Post Offices” in the 
GroupWise 6.5 Administration Guide. When you specify the locations for the post office 
directories, include the shared disks where you want the post office directories to reside. 


When you have completed the worksheet, transfer key information from the Basic GroupWise 
System Worksheet or the Post Office Worksheet to the System Clustering Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 8: Post Office Name, transfer the post office name and directory to the System Clustering 
Worksheet. 


IMPORTANT: Do not create the new post office until you are instructed to do so in Chapter 3, “Setting Up a 
Domain and Post Office in a Novell Cluster,” on page 37. 


Planning a Library for a New Clustered Post Office 


The considerations involved in planning a library in a Microsoft cluster are essentially the same as 
for any other environment. You can plan a library for a new clustered post office by following the 
standard instructions provided in “Creating and Managing Libraries” in the GroupWise 6.5 
Administration Guide and filling out the “Basic Library Worksheet” or the “Full-Service Library 
Worksheet”. Then provide the library information on the System Clustering Worksheet. 
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SYSTEM CLUSTERING WORKSHEET 


Under Item 9: Document Storage Area Location, mark where you want to create the library’s document 
storage area. 


If the document storage area will be located outside the post office directory structure and outside the 
cluster, specify a user name and password that the POA can use to access the server where the 
document storage area will reside. 


IMPORTANT: Do not create the new library until you are instructed to do so in Chapter 3, “Setting Up a 
Domain and Post Office in a Novell Cluster,” on page 37. 


Planning GroupWise Resource Groups 


Resource groups ensure that resources that depend on each other fail over together. If your 
Group Wise system is very small (for example, one domain and one post office), you could have a 
single GroupWise resource group so that your whole Group Wise system would fail over together. 
More typically, multiple domains and post offices are located throughout your organization, so you 
would set up a resource group for each domain and post office. 


A resource group for a domain or post office must include the following types of resources: 


+ Network Name: The virtual name by which the domain or post office resource group will be 
known on the network, regardless of which node it is active on 


+ IP Address: The virtual IP address that will be associated with the network name, regardless 
of which node the domain or post office resource group is active on 


¢ Physical Disk: The drive letter where the domain or post office directory will be located, used 
when mapping a drive to the physical disk 


¢ File Share: The name of the physical disk, used when mapping a drive to the physical disk 


+ Generic Service: The GroupWise agent, running as a Windows service, that will service the 
domain or post office 


For convenience, you might want to name each resource group after the domain or post office it 
represents. In this documentation, a resource group that could include a domain, a post office, or 
both, is termed a "GroupWise resource group." 


Each Group Wise resource group has associated with it a list of possible owners. The possible 
owners are the nodes to which the resource group could fail over. By default, a resource group is 
configured to have all nodes in the cluster in its possible owners list, organized in ascending 
alphanumeric order. Only one node at a time can have a particular GroupWise resource group 
active. Ifa resource group’s current owner node fails, the resource group fails over to the next node 
in the possible owners list. You will want to customize the owners list for each GroupWise 
resource group based on the fan-out-failover principle. 


When a node fails, its resource groups should not all fail over together to the same node in the 
cluster. Instead, the resource groups should be distributed across multiple nodes throughout the 
cluster. This prevents any one node from shouldering the entire processing load typically carried 
by another node. In addition, some GroupWise resource groups should never have the potential of 
failing over to the same node. For example, a post office and POA that service a large number of 
very active GroupWise client users should never fail over to a node where another very large post 
office and heavily loaded POA reside. If they did, users on both post offices would notice a 
decrease in responsiveness of the GroupWise client. 
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SYSTEM CLUSTERING WORKSHEET 


Under Item 4: Resource Group for Domain, specify the network name and other required information 
for the domain resource group. Mark whether you will place the post office in the same resource group 
with the domain. 


If you want the post office in a different resource group from where the domain is located, under Item 
5: Resource Group for Post Office, specify the network name and other required information for the 
post office resource group. 


Planning Shared Administrative Resources 


Depending on your administrative needs, you might or might not want to set up shared 
administrative resources. For example, you might want to have a shared disk where you install the 
GroupWise snap-ins to ConsoleOne® instead of installing them on multiple administrator 
workstations. You might also have a shared disk where you create the GroupWise software 
distribution directory. These shared disks could be configured to fail over as part of your clustered 
environment. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 3: Resources for GroupWise Administration, list any shared disks you want to use for 
GroupWise administration purposes. 


Ensuring Successful Name Resolution for GroupWise Resource 


Groups 


When you establish Group Wise resource groups, you establish network names for the locations of 
domains and post offices. The network names remain constant no matter which node in the cluster 
the domain or post office is currently active on. Because you are using virtual network names, not 
physical locations, you must ensure that short name resolution is always successful. For example, 
in ConsoleOne, if you right-click a Domain object in the GroupWise View and then click Connect, 
ConsoleOne must be able to resolve the domain database location, as provided in the UNC Path 
field, to the network name of that domain within your cluster. It is through short name resolution 
that all GroupWise resource groups are accessed and managed in ConsoleOne. 


A client program (such as ConsoleOne) that runs on a Windows workstation, can be configured to 
use several different short name resolution methods. To see which methods are in use at a 
particular workstation, view the protocol preferences for the Novell® Client™ that is installed on 
the Windows workstation: 
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Novell Client for Windows 2000 Properties 2 xi 


Single Sign-on | DHCP Settings | Default Capture | 
Advanced Settings | Advanced Menu Settings | 
Client | Location Profiles | Advanced Login | Contextless Login | 
Protocol Preferences | Service Location 


Select a protocol and component to configure 
Preferred Network Protocol: z 


Protocol: Component: 


A 


Protocol component settings- 
MINDS 
M Host File 
MIDNS 

Z SLP 

CO DHCP NDS 


Short name resolution methods that pertain to your clustered GroupWise system are discussed 
below: 


Short Name Description 
Resolution 
Method 


eDirectory You can use Novell eDirectory™ to resolve short names into specific network addresses. 
However, when using eDirectory for short name resolution, you must remember to 
consider current context in the name resolution process. eDirectory short name resolution 
works only if your current context is the same as the context of the eDirectory object you 
need to access. 


Hosts Files Windows uses the following files when performing short name resolution at the 
workstation: 


+ Windows NT/2000/XP: 
\winnt\system32\drivers\etc\hosts 


+ Windows 9.x: 
\novell\client32\nwhosts 


Using these files at the Windows workstation is not a preferred method for short name 
resolution (except perhaps for the administrator's workstation). 


DNS Perhaps the most common short name resolution option is Domain Name Service (DNS). 
As with the hosts file, it is good practice to place all the network names of your GroupWise 
resource groups into DNS. 


For short name resolution to work using DNS, the client workstation must either belong to 
the same DNS zone (such as support.novell.com) as the resource group, or the cluster 
resource zone must be configured in the client's DNS suffix search path under TCP/IP 
settings for the workstation. 


Specific setup instructions for each of these short name resolution methods will be provided in 
Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149. 


138 GroupWise 6.5 Interoperability Guide 


SYSTEM CLUSTERING WORKSHEET 


Under Item 6: IP Address Resolution Methods, mark which methods you want to implement in order 
to resolve the locations stored as UNC paths in ConsoleOne into the network names of the 
GroupWise resource groups. 


Deciding How to Install and Configure the Agents in a Cluster 


There are several cluster-specific issues to consider as you plan to install the Windows MTA and 
POA in your clustered GroupWise system: 


+ “Planning Cluster-Unique Port Numbers for Agents in the Cluster” on page 139 
+ “Deciding Where to Install the Agent Software” on page 141 

+ “Planning the Agent Services” on page 142 

+ “Planning the Windows Agent Installation” on page 143 


Planning Cluster-Unique Port Numbers for Agents in the Cluster 


By default, the GroupWise agents listen on all IP addresses, both primary and secondary, that are 
bound to the server on their specified port numbers. The primary IP address is the IP address of 
the physical node. Secondary IP addresses are the IP addresses associated with Group Wise 
resource groups. 


Any time there is a possibility of two of the same type of agent running on the same node, it is 
important that each agent use a cluster-unique port number, even though each agent is using the 
unique IP address established for each Group Wise resource group. The best way for you to avoid 
port conflicts is to plan your cluster so that each agent in the cluster runs on a cluster-unique port. 
Print out a copy of the “Network Address Worksheet” on page 146 to help you plan cluster-unique 
port numbers for all GroupWise agents in your Group Wise system. 


The following filled-out version of the Network Address Worksheet illustrates one way this can 
be done: 


Domain Information 


MTA MTA MTA 
IP Address MTP Port HTTP Port 


123.45.67.81 7100 7180 


Post Office Information 


Post Office POA POA POA POA 
IP Address C/S Port MTP Port HTTP Port 


Development (same as MTA 1677 7101 7181 
Manufacturing 123.45.67.82 1678 7102 7182 
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Internet Agent Information 


Internet Agent GWIA MTA MTA Live MTA GWIA 

IP Address MTP Port Remote Port HTTP Port| HTTP Port 
GWIA Domain 123.45.67.83 7110 7677 7183 
MTA 


Internet Agent (same as MTA) N/A N/A N/A 9850 
(GWIA) 


WebAccess Information 


WebAccess Agent | WebAccess MTA MTA WebAccess WebAccess 

IP Address MTP Port | HTTP Port | Agent Port HTTP Port 
WebAccess 123.45.67.84 7120 7184 N/A N/A 
Domain MTA 


WebAccess (same as MTA) N/A N/A 7205 7205 
Agent (same as agent) 
(GWINTER) 


This example places the Development post office in the same resource group with the Provol 
domain; therefore, the Provol MTA and the Development POA use the same IP address. The 
Manufacturing post office is placed in a different resource group; so the Manufacturing post office 
has a different IP address. The Internet Agent and the WebAccess Agent each have their own 
domains and separate resource groups. 


The example also illustrates that the MTA, the POA, and the Internet Agent use different port 
numbers for agent ports and HTTP ports. In contrast, the WebAccess Agent uses the same port 
number for the agent port and the HTTP port. 


The example uses default port numbers where possible. For example, the default MTA message 
transfer port is 7100 and the default POA client/server port is 1677. Incrementing port numbers 
are used in the example when multiple components have the same type of ports. For example, port 
numbers 1677 and 1678 are both POA client/server ports and port numbers 7180 through 7184 are 
all HTTP ports. Incrementing from the default port numbers generates unique, though related, port 
numbers. 


If you are going to set up a GroupWise name server to help GroupWise clients locate their post 
offices, make sure that the default POA port number of 1677 is used somewhere in the cluster and 
specify the IP address of the post office resource group, not the IP address of a specific node. For 
more information, see “Simplifying Client/Server Access with a GroupWise Name Server” in 
“Post Office Agent” in the GroupWise 6.5 Administration Guide. 


NETWORK ADDRESS WORKSHEET 


Fill out the “Network Address Worksheet’ on page 146 to help you determine resource group IP 
addresses and cluster-unique port numbers for all GroupWise agents in the cluster. (MTA, POA, 
Internet Agent, WebAccess Agent). Refer to the IP addresses you planned for the domain and post 
office resource groups under items 4 and 5 on the System Clustering Worksheet. 
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After you have filled out the Network Address Worksheet, transfer the IP addresses and the cluster- 
unique port numbers from the Network Address Worksheet to the Agent Clustering Worksheet so 
that they will be available in the sequence in which you will need them as you set up the 
GroupWise agents in the cluster. 


AGENT CLUSTERING WORKSHEET 


Under Item 4: MTA Network Information, transfer the resource group IP address and cluster-unique 
port numbers for the MTA from the Network Address Worksheet to the Agent Clustering Worksheet. 


Under Item 7: POA Network Information, transfer the resource group IP address and cluster-unique 
port numbers for the POA from the Network Address Worksheet to the Agent Clustering Worksheet. 


Deciding Where to Install the Agent Software 


In a Microsoft cluster, the agents must run as Windows services. When you install the Windows 
MTA and POA, you can choose between two different installation locations: 


Location Description 

Each node in the The c:\grpwise directory is the default location provided by the Agent Installation 
cluster program. 

Shared disk If you create a drive:\grpwise directory on the same shared disk with the domain 


or post office directory, the agent software and startup files fail over and back 
with the domains and post offices that the agents service. 


Because the agents must be installed as Windows services in a Microsoft cluster, you must initially 
run the Agent Installation program for each node in the cluster so that the Windows services for 
the agents get created, regardless of where you are planning to run the agents from. However, for 
updates, you need to run the Agent Installation program only once if you are running the agents 
from a shared disk. 


The following sections can help you choose which installation location would be best for your 
clustered GroupWise system: 


e “Advantages of Installing to a Shared Disk” on page 141 
¢ “Disadvantages of Installing to a Shared Disk” on page 142 


+ “Recommendation” on page 142 


Advantages of Installing to a Shared Disk 


Using a drive:\grpwise directory for each GroupWise shared disk has several advantages: 


+ When you update the agent software, you only need to update it in one place for a particular 
domain or post office, not on every node in the resource group’s possible owners list. This 
prevents the potential problem of having a domain or post office fail over to a node where a 
different version of the agent software is installed. 


+ Having the agent startup files on the same node as the domain or post office makes them easy 
to find. 


¢ If you change information in the agent startup files, you only need to change it in one place, 
not on every node in the resource group’s possible owners list. 


+ If you want to back up the GroupWise data, you can back up the domain and/or post office 
directories and the agent software from the same shared disk. 
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Disadvantages of Installing to a Shared Disk 


Recommendation 


Installing the agents on the same shared disk with a domain or post office does have some 
disadvantages: 


+ You must install the agent software each time you create a new domain or post office on a new 
shared disk. 


+ GroupWise administrators who are used to the Group Wise agents being installed in c:\grpwise 
might be confused by not finding them there in the clustered GroupWise system. 


+ You must remember where you installed the GroupWise agents when you update the agent 
software. Accidently installing a GroupWise Support Pack to the default location of 
c:\grpwise on the active node would not have the desired results if the original agent software 
was installed to a shared disk. 


Whichever method you choose, be consistent throughout the entire cluster. Either put all the 
Group Wise agents on the shared disks with the domains and post offices they service, or put them 
all in c:\grpwise directories on all nodes. If you put them on shared disks with domains and post 
offices, make sure there are no agent files in c:\grpwise directories on nodes to confuse the issue 
at a later time. 


Even if you choose to install the agents to the c:\grpwise directory of multiple nodes, you can still 
store the agent startup files on shared disks with the domains and post offices. The significant 
advantage of this approach is that you only have one startup file to modify per agent. 


AGENT CLUSTERING WORKSHEET 


Under Item 1: Agent Installation Location, mark whether you will install the agent software to the 
shared disk with a domain or post office, or to each node in the cluster. If necessary, specify where 
the agent startup files will be stored. 


Under Item 2: Domain Name, transfer the domain name, shared disk, and directory from the System 
Clustering Worksheet to the Agent Clustering Worksheet. 


Under Item 5: Post Office Name, transfer the post office name, shared disk, and directory from the 
System Clustering Worksheet to the Agent Clustering Worksheet. 


Planning the Agent Services 


In a Microsoft cluster, the MTA and POA must be set up as service resources. A service resource 
for a GroupWise agent must include the following information: 


+ Name: The name by which the agent service will be listed in the resource group (for example, 
MTA Service or POA Service) 


+ Possible Owners: The list of nodes in the cluster to which the Group Wise agent can fail over 
(the same as the possible owners of the resource group to which the agent service belongs) 


+ Resource Dependencies: Other resources in the resource group that must be online before the 
GroupWise agent can start on a new node (for example, the Group IP Address resource and 
the Physical Disk resource where the domain or post office directory is located) 
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AGENT CLUSTERING WORKSHEET 


Under Item 3: MTA Service Resource, specify the MTA service resource name and list any possible 
resource dependencies. 


Under Item 6: POA Service Resource, specify the POA service resource name and list any possible 
resource dependencies. 


Planning the Windows Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the GroupWise Windows agents are the same in a Microsoft cluster 
as in any other environment. Review “Planning the GroupWise Agents”, then print and fill out the 
“Group Wise Agent Installation Worksheet” in “Installing GroupWise Agents” in the GroupWise 
6.5 Installation Guide for each location where you will install the Windows MTA and/or POA. 


Fill out the Windows Agent Worksheet, taking into account the following cluster-specific issues: 


GROUPWISE AGENT INSTALLATION WORKSHEET 


Under Item 2: Agents and Locations, mark POA Local to Post Office and MTA Local to Domain. Ina 
Microsoft cluster, a domain or post office and its agent must be located on the same node in order to 
fail over together. 


Under Item 3: Installation Path, take into account your decision based on “Deciding Where to Install 
the Agent Software” on page 141. 


Under Item 8: Installation Options, mark Install as Windows Services. 


Under Item 6: Domains and Item 7: Post Offices, refer to the Domain and Post Office Worksheets you 
filled out during “Planning a New Clustered Domain” on page 134 and “Planning a New Clustered Post 
Office” on page 135, and to the Network Address Worksheet you completed during “Planning Cluster- 
Unique Port Numbers for Agents in the Cluster” on page 139. 


IMPORTANT: Do not install the Windows agent software until you are instructed to do so in Chapter 14, 
“Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149. 


Continue with Chapter 14, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 149. 
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GroupWise Clustering Worksheets 


¢ “System Clustering Worksheet” on page 144 


+ “Network Address Worksheet” on page 146 


+ “Agent Clustering Worksheet” on page 147 


System Clustering Worksheet 


Item 


1) Cluster Name: 


2) Nodes in Cluster: 


3) Resources for GroupWise Administration: 


ConsoleOne: 
Shared disk: 
Possible owners: 


Software Distribution Directory: 
Shared disk: 
Possible owners: 


4) Resource Group for Domain: 


Network name: 
IP address: 
Physical disk: 
File share: 

MTA service: 
Possible owners 


Post Office in Same Resource Group as 
Domain? 


+ Yes 


+ No 


5) Resource Group for Post Office: 


Network name: 
IP address: 
Physical disk: 
File share: 

MTA service: 
Possible owners 
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Explanation 


Record the name of the name of your Microsoft cluster. 


For more information, see “Setting Up Your Microsoft Cluster” on page 134. 


List the servers that are part of the cluster that you set up for your GroupWise 
system. 


For more information, see “Setting Up Your Microsoft Cluster” on page 134. 


List any shared locations that you want to set up for ConsoleOne or the 
software distribution directory. 


For more information, see “Planning Shared Administrative Resources” on 
page 137. 


Specify the information for the domain resource group. 


For more information, see “Planning a New Clustered Domain” on page 134. 


Specify the information for the post office resource group. 


For more information, see “Planning a New Clustered Post Office” on 
page 135. 


Item Explanation 


6) IP Address Resolution Methods: Mark the short name address resolution methods you want to implement to 
ensure that the UNC paths stored in ConsoleOne with network names can 


ee Oy be successfully resolved into physical network addresses. 


+ hosts file , , ; . 
For more information, see “Ensuring Successful Name Resolution for 
* DNS GroupWise Resource Groups” on page 137 
7) Domain Name: Specify a unique name for the domain. Specify the directory where you want 
Domain Directory: to create the new domain. 
For more information, see “Planning a New Clustered Domain” on page 134. 
8) Post Office Name: Specify a unique name for the post office. Specify the directory where you 
Post Office Directory: want to create the post office. 
For more information, see “Planning a New Clustered Post Office” on 
page 135. 
9) Document Storage Area Location: If you need a library for a clustered post office, mark where you want to 


+ At the post office create its document storage area and provide a directory if necessary. 


For more information, see “Planning a Library for a New Clustered Post 


+ Outside the post office 
Office” on page 135. 


¢ Separate post office 

Document Storage Area Access 

+ POA /user startup switch setting 

+ POA /password startup switch setting 


Planning GroupWise in a Microsoft Cluster 145 


Network Address Worksheet 


Domain Information 


MTA MTA MTA 
IP Address MTP Port HTTP Port 


Post Office Information 


Post Office POA POA POA POA 
IP Address C/S Port MTP Port HTTP Port 


Internet Agent Information 


Internet Agent GWIA MTA MTA MTA GWIA 
IP Address MTP Port Live Remote Port HTTP Port HTTP Port 


| GWIA Domain MTA | Domain Ma 


Internet = a 
(GWIA) 


WebAccess Information 


WebAccess Agent | WebAccess MTA MTA WebAccess Agent WebAccess 

IP Address MTP Port HTTP Port Port HTTP Port 
WebAccess N/A N/A 
Domain MTA 


WebAccess Agent | (same) N/A N/A 
(GWINTER) 
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Agent Clustering Worksheet 


Item 


1) Agent installation location: 
¢ Shared disk with domain or post office 


+ Each node in the cluster 


Consolidate startup files? 


2) Domain Name: 
Domain Directory: 


3) MTA Service Resource: 


Service name: 
Possible owners: 
Resource dependencies: 


4) MTA Network Information: 


MTA IP address: 
MTA message transfer port: 
MTA HTTP port: 


5) Post Office Name: 


Post Office Directory: 


6) POA Service Resource: 


Service name: 
Possible owners: 
Resource dependencies: 


7) POA Network Information: 
POA IP address 
POA client/server port 
POA message transfer port 
POA HTTP port 


Explanation 
Mark the location where you will install the agent software. 


If necessary, specify the location where you will store agent startup files 
on the same shared disk with the domain or post office. 


For more information, see “Deciding Where to Install the Agent Software” 
on page 141. 


Transfer this information from the System Clustering Worksheet (item 6). 


List other nodes in the cluster where the domain resource group could fail 
over and any resources that must be online before the MTA can start. 


For more information, see “Planning the Agent Services” on page 142. 


Gather the MTA network address information from the “Network Address 
Worksheet” on page 146. 


For more information, see “Planning Cluster-Unique Port Numbers for 
Agents in the Cluster” on page 139. 


Transfer this information from the System Clustering Worksheet (item 7). 


List other nodes in the cluster where post office resource group could fail 
over and any resources that must be online before the POA can start. 


For more information, see “Planning the Agent Services” on page 142. 


Gather the POA network address information from the “Network Address 
Worksheet” on page 146. 


For more information, see “Planning Cluster-Unique Port Numbers for 
Agents in the Cluster” on page 139. 
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Setting Up a Domain and Post Office ina 
Microsoft Cluster 


You should have already reviewed “Planning Group Wise in a Microsoft Cluster” on page 133 and 
filled out the “System Clustering Worksheet” on page 144, the “Network Address Worksheet” on 
page 146, and the “Agent Clustering Worksheet” on page 147. You are now ready to complete the 
following tasks to set up GroupWise® in your Microsoft cluster: 


+ “Preparing the Cluster for GroupWise” on page 149 

+ “Setting Up a New GroupWise System in a Cluster” on page 151 

+ “Creating a New Secondary Domain in a Cluster” on page 152 

+ “Creating a New Post Office in a Cluster” on page 153 

+ “Installing and Configuring the MTA and the POA in a Cluster” on page 154 
+ “Testing Your Clustered GroupWise System” on page 156 

+ “Managing Your Clustered GroupWise System” on page 157 

+ “What’s Next” on page 159 


Preparing the Cluster for GroupWise 


After you have set up your Microsoft cluster and become familiar with its functioning, as described 
in Chapter 12, “Introduction to Group Wise 6.5 and Microsoft Clusters,” on page 131, complete the 
following tasks to prepare the cluster for your GroupWise system: 


+ “Creating GroupWise Resource Groups” on page 149 
+ “Creating Agent Service Resources” on page 149 


+ “Configuring Short Name Resolution” on page 150 


Creating GroupWise Resource Groups 
Create the needed domain and post office resource groups in your Microsoft cluster (System 
Clustering Worksheet items 3 and 4), as planned in “Planning a New Clustered Domain” on 
page 134 and “Planning a New Clustered Post Office” on page 135. 

Creating Agent Service Resources 


Within each Group Wise resource group, create the MTA or POA service resource (Agent 
Clustering Worksheet items 3 and 6), as planned in “Planning the Agent Services” on page 142. 
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Configuring Short Name Resolution 


eDirectory 


Hosts Files 


To ensure that Group Wise resource groups are always locatable on the network, configure the 
short name resolution methods that you want to rely on for your clustered GroupWise system 
(System Clustering Worksheet item 9), as planned in “Ensuring Successful Name Resolution for 
GroupWise Resource Groups” on page 137. 


¢ “eDirectory” on page 150 
+ “Hosts Files” on page 150 
+ “DNS” on page 151 


After configuring your selected short name resolution methods, continue with the task you need to 
perform: 


+ “Setting Up a New GroupWise System in a Cluster” on page 151 
+ “Creating a New Secondary Domain in a Cluster” on page 152 


+ “Creating a New Post Office in a Cluster” on page 153 


ConsoleOne® will use Novell® eDirectory™ to resolve the UNC path of a domain or post office 
directory into its network name in the cluster. For example, on the workstation where you run 
ConsoleOne, you would need to map a drive to the location of a domain directory using the 
network name of the domain resource group so that ConsoleOne can access the domain database 
no matter which node in the cluster it is active on. 


Because each GroupWise resource group has been associated with a network name, you should 
add lines for the new network names to one or more of the following files as needed: 


+ Windows NT*/2000: 
\winnt\system32\drivers\etc\hosts 
(on the administrator’s workstation only; optional) 


+ Windows 9x: 
\novell\client32\nwhosts 
(on the administrator’s workstation only; optional) 


The lines you add to a hosts file could look similar to the following example (all on one line, of 
course): 


Syntax: 
IP_address network_name.context 


Remember that network_name represents the name of the virtual server that remains unchanged 
regardless of which node is currently active. 


Example: 
123.45.67.81 gwcluster.novell.com 


When specifying the lines in the hosts files, use System Clustering Worksheet item 7 or 8 for each 
IP_address and network_name where a domain or post office resides. Use System Clustering 
Worksheet item 3 for cluster. Use System Clustering Worksheet item 4 for context. 
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DNS 


Because each Group Wise resource group has been associated with a virtual network name, you 
should add all your new network names to DNS. 


Setting Up a New GroupWise System in a Cluster 


The Group Wise Installation Advisor walks you through setting up the primary domain and an 
initial post office in the primary domain. You might be creating your primary domain and initial 
post office in the same resource group or in two different resource groups. After you have created 
the primary domain and initial post office and installed the GroupWise agents, you can create 
additional secondary domains and post offices in the cluster as needed. 


To set up the primary domain and initial post office for a new Group Wise system in a Microsoft 
cluster: 


1 


2 


If necessary, map a drive to each GroupWise administration shared disk (System Clustering 
Worksheet item 3). 


Map a drive to the shared disk of the domain resource group (System Clustering Worksheet 
item 6) and, if needed, to the shared disk of the post office resource group (System Clustering 
Worksheet item 7), where the primary domain and the initial post office for your new 
GroupWise system will be created. 


Manually create the domain directory (System Clustering Worksheet item 6) and the post 
office directory (System Clustering Worksheet item 7). 


This step is not required, but in a Microsoft cluster, the following step will be easier if the 
directory already exists. 


Run the GroupWise Installation Advisor to set up your initial Group Wise system, following 
the steps provided in “Setting Up a Basic GroupWise System on NetWare or Windows” in 
“Installing a Basic GroupWise System” in the GroupWise 6.5 Installation Guide. Keep in 
mind the following cluster-specific details: 


+ When you specify the ConsoleOne directory and the software distribution directory, be 
sure to browse to each location through the shared disk accessed in Step | above. 


+ When you specify the domain directory and post office directory, be sure to browse 
through the shared disk accessed in Step 2 to select the directory created in Step 3 above. 


¢ For the post office link type, select TCP/IP Link. 


+ When providing the MTA and POA network address information, use the Agent 
Clustering Worksheet that you filled out during “Deciding How to Install and Configure 
the Agents in a Cluster” on page 139. The information you provide will be used to 
configure the MTA and POA objects in the domain and post office even though you have 
not yet installed the agent software. 


¢ Do not worry about creating users in the post office at this time. 


+ Inthe Summary dialog box, the domain directory and post office directory that you 
browsed to should display as UNC paths using the network name of the Group Wise 
resource group, not the name of a specific node in the cluster. 


When you have finished creating the primary domain and the initial post office, continue with 
installing the GroupWise Agents, starting with Step 5 in “Installing the Agent Software in a 
Cluster” on page 155. 


The GroupWise Installation Advisor starts the Agent Installation program for you. 
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Creating a New Secondary Domain in a Cluster 


After you have set up the primary domain and initial post office, as described in “Setting Up a New 
Group Wise System in a Cluster” on page 151, you can create additional secondary domains as 
needed. 


To create a new secondary domain in a Microsoft cluster: 


1 Create a domain resource group for the new domain, as described in “Creating GroupWise 
Resource Groups” on page 149. 


2 Create an MTA service resource for the domain’s MTA, as described in “Creating Agent 
Service Resources” on page 149. 


3 Map a drive to the shared disk of the domain resource group (System Clustering Worksheet 
item 7) where the new secondary domain will be created. 


4 Manually create the domain directory (System Clustering Worksheet item 7). 


This step is not required, but in a clustered environment, Step 7 will be easier if the domain 
directory already exists. 


5 Ifyou selected the same shared disk with the domain as the agent installation location (Agent 
Clustering Worksheet item 1), create the drive:\grpwise directory on the drive accessed in 
Step 3. 


or 


If you selected c:\grpwise on each node in the cluster, decide which node you will install the 
agents to first. 


6 In ConsoleOne, connect to the primary domain in your GroupWise system, as described in 
“Connecting to a Domain” in “Domains” in the GroupWise 6.5 Administration Guide. 


7 Create the new domain, following the steps provided in “Creating the New Domain” in 
“Domains” in the GroupWise 6.5 Administration Guide. Keep in mind the following cluster- 
specific details: 


+ Use the Domain Worksheet you filled out during “Planning a New Clustered Domain” on 
page 134 to fill in the fields on the Create GroupWise Domain page. 


+ Inthe Domain Database Location field, be sure to browse through the drive you accessed 
in Step 3 to the domain directory you created in Step 4 above. 


+ Inthe Link to Domain field, link the new domain to the primary domain of your 
GroupWise system. 


+ The Configure Link option is selected by default. Select TCP/IP Link to the Other 
Domain. Refer to the Agent Clustering Worksheet that you filled out during “Planning 
Cluster-Unique Port Numbers for Agents in the Cluster” on page 139 for the resource 
group IP address and cluster-unique port numbers that you need to specify in order to 
configure the link. 


8 Use the Link Configuration tool to change the links from the new domain to all other domains 
in the cluster to direct TCP/IP links, following the steps provided in “Changing the Link 
Protocol between Domains to TCP/IP” in “Message Transfer Agent” in the GroupWise 6.5 
Administration Guide. 


Although a complete mesh link configuration is the most efficient, it might not be feasible in 
all situations. Set up as many direct TCP/IP links as possible for best MTA performance in the 
cluster. 
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9 
10 


11 


Make sure you are still connected to the primary domain. 


Rebuild the domain database for the new domain, following the steps provided in “Rebuilding 
Domain or Post Office Databases” in “Databases” in the GroupWise 6.5 Administration 
Guide. Be sure to browse to the database location (System Clustering Worksheet item 7) 
through the shared disk you accessed in Step 3 to the domain directory you created in Step 4 
above. 


The database rebuild is necessary in order to transfer the MTA configuration information and 
the domain link information into the secondary domain database, because the MTA for the 
new secondary domain is not yet running. 


Continue with “Creating a New Post Office in a Cluster” on page 153. 


Creating a New Post Office in a Cluster 


You can create a new post office in the same resource group where its domain is located or in a 
separate resource group. If the post office and its domain are in the same resource group, they fail 
over together. If they are in separate resource groups, they fail over separately. 


To create a new post office in a Microsoft cluster: 


1 


4 


If you selected Yes for Post Office in Same Resource Group as Domain? (under System 
Clustering Worksheet item 4), map a drive to the shared disk of the domain resource group. 


or 
Map a drive to the shared disk of the post office resource group (System Clustering Worksheet 
item 5). 

Manually create the post office directory (System Clustering Worksheet item 8). 


This step is not required, but in a Microsoft cluster, Step 4 will be easier if the post office 
directory already exists. 


In ConsoleOne, connect to the GroupWise domain where you want to create the new post 
office, as described in “Connecting to a Domain” in “Domains” in the GroupWise 6.5 
Administration Guide. 


Create the new post office, following the steps provided in “Creating the New Post Office” in 
“Post Offices” in the GroupWise 6.5 Administration Guide. Keep in mind the following 
cluster-specific details: 


+ Use the Post Office Worksheet you filled out during “Planning a New Clustered Post 
Office” on page 135 to fill in the fields on the Create Group Wise Post Office page. 


+ Inthe Post Office Database Location field, be sure to browse through the shared disk you 
accessed in Step | to the post office directory you created in Step 2 above. 


+ Ifyou want to create a library at the post office (System Clustering Worksheet item 9), 
select Create Library. 


+ The Configure Link option is selected by default. Select TCP/IP Link from Domain to 
New Post Office. Refer to the Agent Clustering Worksheet that you filled in during 
“Planning Cluster-Unique Port Numbers for Agents in the Cluster” on page 139 for the 
resource group IP address and cluster-unique port numbers that you need to specify in 
order to configure the link. 


In ConsoleOne, right-click the new Post Office object, then click Properties. 
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6 Click GroupWise > Post Office Settings, then in the Access Mode field, select Client/Server 
Only. 


7 Right-click the new POA object, then click Properties. 


On the POA Agent Settings and Scheduled Events pages, you might want to specify unique 
times for the following POA activities to prevent multiple POAs from performing the same 
activities on the same node at the same time during a failover situation: 


¢ Start User Upkeep 

+ Generate Address Book for Remote 
¢ Enable QuickFinder Indexing 

+  Mailbox/Library Maintenance Event 


For more information about these repetitive POA activities, see “Performing Nightly User 
Upkeep”, “Regulating Indexing”, and “Scheduling Database Maintenance” in “Post Office 
Agent” in the GroupWise 6.5 Administration Guide. 


8 Make sure you are still connected to the domain that owns the new post office. 


9 Rebuild the post office database for the new post office, following the steps provided in 
“Rebuilding Domain or Post Office Databases” in “Databases” in the GroupWise 6.5 
Administration Guide. Be sure to browse to the database location (System Clustering 
Worksheet item 7) through the shared disk you accessed in Step | to the post office directory 
you created in Step 2 above. 


The database rebuild is necessary in order to transfer the POA configuration information and 
the post office link information into the post office database, because the POA for the new 
post office is not yet running. 


10 Ifyou want to create a library (System Clustering Worksheet item 9) for the new clustered post 
office, follow the steps in “Setting Up a Basic Library” or “Setting Up a Full-Service Library” 
in “Libraries and Documents” in the GroupWise 6.5 Administration Guide, after you have 
completely finished setting up the new clustered post office. 


11 Continue with “Installing and Configuring the MTA and the POA in a Cluster” on page 154. 
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After you have created a new domain and/or post office, you are ready to install and configure the 
GroupWise agents. Complete all the tasks below if you are setting up a new GroupWise system or 
if you have created a new GroupWise resource group where you want to install the agent software: 


+ “Installing the Agent Software in a Cluster” on page 155 
¢ “Editing Clustered Agent Startup Files” on page 155 


Under some circumstances, the agent software has already been installed in the cluster and you 
simply need to create a new startup file specific to the new domain or post office. For example: 


+ You have created a new domain and/or post office in a GroupWise resource group where the 
agent software is already installed in the drive:\grpwise directory for the resource group. 


¢ In your GroupWise system, the agent software is already installed to the c:\grpwise directory 
on each node in the cluster. 


In these circumstances, follow the instructions in “Setting Up New Instances of the Agents without 
Installing the Agent Software” on page 156 instead of completing the tasks listed above. 
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Installing the Agent Software in a Cluster 
To install the MTA and the POA: 


1 Map a drive to the shared disk of the domain resource group (Agent Clustering Worksheet 
item 2) or the post office resource group (Agent Clustering Worksheet item 5). 


2 Map a drive to c:\ on the first node in the cluster where you will set up the agents as Windows 
services (System Clustering Worksheet item 2). 


3 Ifyou plan to install the agent software to the shared disk of the domain or post office resource 
group (under Agent Clustering Worksheet item 1), create the drive:\grpwise directory on the 
shared disk accessed in Step 1. 


or 


If you plan to install the agent software to each node in the cluster, create the c:\grpwise 
directory on the drive accessed in Step 2. 


4 Start the Agent Installation program, following the steps provided in “Installing the Windows 
Agent Software” in “Installing GroupWise Agents” in the GroupWise 6.5 Installation Guide. 


5 Install the Windows agents, keeping in mind the following cluster-specific details: 


+ Use the Windows Agent Clustering Worksheet that you filled out during “Planning the 
Windows Agent Installation” on page 143 to fill in the fields during the agent installation 
process. 


+ On the Installation Path page, be sure to browse through the mapped drive to the directory 
you created in Step 3 above. Be sure that Install as Windows Services is selected. 


+ On the Domains / Post Offices page, click Add for each domain and post office that the 
agents will service. In the Path to Database field, be sure to browse through the drive you 
mapped in Step | above to the domain directory or the post office directory on the shared 
disk. 


+ On the Installation Complete page do not select Launch GroupWise Agents Now. 


6 Ifyou need to install the agent software to c:\grpwise on each node in the cluster, repeat Step 4 
and Step 5, mapping a drive to each node in the cluster. 


or 


If you installed the agent software to a shared disk and need only to set up the agents as 
Windows services on each node, repeat Step 4 and Step 5, mapping drives to new nodes as 
needed. On the Installation Options page, select only the Install as Windows Services option 
to speed up the installation process for each node. 


7 Ifyou installed the agent software to each node and you selected Yes for Consolidate Startup 
Files? (under Agent Clustering Worksheet item 1), copy one complete set of agent startup files 
to the planned location on the shared disk, then delete all agent startup files from the 
c:\grpwise directories on the nodes to avoid future confusion. 


8 Continue with “Editing Clustered Agent Startup Files” on page 155. 


Editing Clustered Agent Startup Files 


By default, the Agent Installation program creates agent startup files in the agent installation 
directory. Each MTA startup file is named after the domain it services, with a .mta extension. Each 
POA startup file is named after the post office it services, with a .poa extension. 
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Because you mapped a drive to the shared disk of the Group Wise resource group using the physical 
disk and file share information from the resource group, the setting for the MTA /home startup 
switch and the POA /home startup switch will always be correct, no matter which node in the 
cluster the domain and post office are currently active on. 


One manual modification of POA startup files is required for robust functionality in a Microsoft 
cluster. Uncomment the /ip startup switch and provide the IP address of the post office resource 
group (Agent Clustering Worksheet item 7). This information is available to the POA in its 
eDirectory object properties. However, in some failover situations, the POA reconnects to the 
MTA more quickly when the information is immediately available to the POA in its startup file. 


If the POA needs to access a remote document storage area that is outside the cluster, add the /user 
and /password startup switches (under System Clustering Worksheet item 9) in order to provide a 
user name and password that the POA can use to access the server where the document storage 
area resides. As an alternative to startup switches, you can assign the POA object all rights except 
Supervisor and Access control, as long as the remote document storage area is located in the same 
tree with the post office. 


Continue with “Testing Your Clustered GroupWise System” on page 156. 


Setting Up New Instances of the Agents without Installing the Agent Software 


To set up new instances of the agents without installing the agent software, you simply create new 
startup files. Each MTA startup file is named after the domain it services, with a .mta extension. 
Each POA startup file is named after the post office it services, with a .poa extension. 


If the existing agent software is located in the drive:\grpwise directory of a shared disk with a 
domain or post office, the startup files will be located there as well. If the existing agent software 
is located in the c:\grpwise directory on each node in the cluster, the startup files might be located 
there, or they might be located on the shared disk with the domain or post office. 


To create a new startup file without installing the agent software: 


1 Make a copy of an existing startup file and name it after the domain or post office that will be 
serviced by the new instance of the agent. 


2 Edit the setting of the /home startup switch to point to the location of the new domain directory 
or post office directory. Be careful to maintain the syntax of the original line, using the 
physical disk and file share provided in the GroupWise resource group. 


3 Scroll down through the startup file looking for other active (not commented out) startup 
switches, then modify them as needed for the new instance of the agent. 


4 Save the new startup file. 


5 Continue with “Testing Your Clustered GroupWise System” on page 156. 


Testing Your Clustered GroupWise System 


After you have configured the GroupWise resource group, you can test the failover and failback 
functionality by bringing the GroupWise resource group online and taking it offline again. 


Continue with “Managing Your Clustered GroupWise System” on page 157. 
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Managing Your Clustered GroupWise System 
After you have set up a basic clustered GroupWise system, you should consider some long-term 
management issues. 
+ “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 157 
+ “Knowing What to Expect in MTA and POA Failover Situations” on page 158 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After setting up your clustered Group Wise system, while the cluster-specific information is fresh 
in your mind, you should record that cluster-specific information as part of the GroupWise objects 
in ConsoleOne so that you can easily refer to it later. Be sure to keep the information recorded in 
the GroupWise objects up to date if the configuration of your system changes. 


+ “Recording Cluster-Specific Information for a Domain and Its MTA” on page 157 
+ “Recording Cluster-Specific Information for a Post Office and Its POA” on page 157 


+ “Recording Cluster-Specific Information for a Software Distribution Directory” on page 158 


Recording Cluster-Specific Information for a Domain and Its MTA 


To permanently record important cluster-specific information for the domain: 
1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 In the Description field of the domain Identification page, provide a cluster-specific 
description of the domain, including the resource group IP address and the cluster-unique port 
numbers used by its MTA. 


Click OK to save the domain description. 
Select the Domain object to display its contents. 


Right-click the MTA object, then click Properties. 


oa bh W 


In the Description field of the MTA Identification page, record the domain resource group IP 
address and the cluster-unique port numbers used by the MTA. 


This information will appear on the MTA console, no matter which node in the cluster it is 
currently running on. 


7 Click OK to save the MTA description. 
8 Continue with “Recording Cluster-Specific Information for a Post Office and Its POA” on 
page 157. 


Recording Cluster-Specific Information for a Post Office and Its POA 


To permanently record important cluster-specific information for a post office: 
1 In ConsoleOne, browse to and right-click the Post Office object, then click Properties. 


2 In the Description field of the post office Identification page, provide a cluster-specific 
description of the post office, including the resource group IP address and the cluster-unique 
port numbers used by its POA. 


3 Click OK to save the post office description. 
4 Select the Post Office object to display its contents. 
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5 Right-click the POA object, then click Properties. 


6 In the Description field of the POA Identification page, record the post office resource group 
IP address and the cluster-unique port numbers used by the POA. 


This information will appear on the POA console, no matter which node in the cluster it is 
currently running on. 


7 Click OK to save the POA description. 


8 Ifnecessary, continue with “Recording Cluster-Specific Information for a Software 
Distribution Directory” on page 158. 


or 


Continue with “Knowing What to Expect in MTA and POA Failover Situations” on page 158. 


Recording Cluster-Specific Information for a Software Distribution Directory 


To permanently record important cluster-specific information about a software distribution 
directory located on a shared disk: 


1 In ConsoleOne, click Tools > System Operations > Software Directory Management. 
2 Select the software distribution directory, then click Edit. 


3 In the description field, record the IP address of the cluster resource where the software 
distribution directory resides. 


4 Click OK, then click Close to save the software distribution directory description. 


5 Continue with “Knowing What to Expect in MTA and POA Failover Situations” on page 158. 


Knowing What to Expect in MTA and POA Failover Situations 


In a failover situation, the agents might need to perform some database repair as they start on the 
new node. The time required depends on the size of the databases involved. 


Typically, the POA returns to full functionality faster than the MTA. This benefits Group Wise 
client users who can reconnect to their mailboxes very quickly and probably will not notice if 
messages to users in other post offices are not delivered immediately. The only time a user would 
need to restart the Group Wise client would be if he or she was actually in the process of sending a 
message when the POA went down. Notify can continue running even if the connection to the POA 
becomes unavailable and then it reconnects automatically when the POA is again available. 


The MTA typically takes some time reestablishing the links to its post offices, other domains, and 
gateways, but this situation usually resolves itself in a few minutes without administrator 
intervention. If it does not, you can manually restart the MTA to speed up the process. 


In comparison to failover, manual migration typically takes longer because the agents 
methodically terminate their threads and close their databases as part of their normal shutdown 
procedure. However, as a result, no database repair is required when the agents start up again in 
their new location. 


Continue with “What’s Next” on page 58. 
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What’s Next 


Now that you have at least one GroupWise domain and post office up and running in your 
Microsoft cluster, you are ready to proceed with the rest of your GroupWise system setup by: 


+ 


+ 


Adding users to post offices. See “Users” in the Group Wise 6.5 Administration Guide. 


Setting up the GroupWise client software and helping users to get started using it. See “Client” 
in the GroupWise 6.5 Administration Guide. Also see the Group Wise 6.5 Windows Client User 
Guide. 


Connecting your clustered GroupWise system to the Internet. See Chapter 4, “Implementing 
the Internet Agent in a Novell Cluster,” on page 63. 


Providing access to users’ GroupWise mailboxes from their Web browsers. See Chapter 5, 
“Implementing WebAccess in a Novell Cluster,” on page 83. 


Connecting your clustered GroupWise system to other e-mail systems through GroupWise 
gateways. See Chapter 6, “Implementing GroupWise Gateways in a Novell Cluster,” on 
page 103. 


Monitoring the status of your clustered GroupWise system from your Web browser. See 
Chapter 7, “Monitoring a GroupWise System in a Novell Cluster,” on page 105. 


Backing up your clustered GroupWise system. See Chapter 8, “Backing Up a GroupWise 
System in a Novell Cluster with the GroupWise TSA,” on page 107. 
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Implementing the Internet Agent in a Microsoft 
Cluster 


You should already have set up at least a basic GroupWise™ system, as described in Chapter 13, 
“Planning Group Wise in a Microsoft Cluster,” on page 133 and Chapter 14, “Setting Up a Domain 
and Post Office in a Microsoft Cluster,” on page 149. As part of this process, the “System 
Clustering Worksheet” on page 144 and the “Network Address Worksheet” on page 146 were 
filled out. If you do not have access to the filled-out worksheets, print the worksheets now and fill 
in the clustering and network address information as it currently exists on your system. You will 
need this information as you implement the Internet Agent in a cluster. 


+ “Planning the Internet Agent in a Cluster” on page 161 

¢ “Setting Up the Internet Agent in a Cluster” on page 164 
+ “Managing the Internet Agent in a Cluster” on page 168 
+ “Internet Agent Clustering Worksheet” on page 170 


Planning the Internet Agent in a Cluster 


A main system configuration difference between a GroupWise system in a clustering environment 
and a GroupWise system in a regular environment is that you need to create a separate domain to 
house each GroupWise gateway, including the Internet Agent. The Internet Agent is faster and 
more stable when it runs on the same server with its domain. In a cluster, creating a separate 
domain for the Internet Agent ensures that the Internet Agent and its domain always fail over 
together. 


The “Internet Agent Clustering Worksheet” on page 170 lists all the information you will need as 
you set up the Internet Agent in a Microsoft cluster. You should print the worksheet and fill it out 
as you complete the tasks listed below: 


+ “Planning a Domain for the Internet Agent” on page 162 

+ “Planning the Internet Agent Resource Group” on page 162 

+ “Planning Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on page 162 
+ “Preparing Your Firewall for the Internet Agent” on page 163 

+ “Deciding Where to Install the Internet Agent and Its MTA” on page 163 

+ “Planning the MTA Installation” on page 164 

¢ “Planning the Internet Agent Installation” on page 164 
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Planning a Domain for the Internet Agent 


The considerations involved in planning a domain for the Internet Agent are much the same as 
planning any other domain. In preparation, review “Planning a New Domain”, then print and fill 
out the “Domain Worksheet” in “Domains” in the GroupWise 6.5 Administration Guide. 


Keep in mind the following cluster-specific details: 


+ When you specify the location for the domain directory on the Domain Worksheet, include 
the shared disk where you want the domain directory to be located. 


+ Do not concern yourself with the GroupWise agent information on the Domain Worksheet. 
You can stop with item 10. You will plan the MTA installation later. 


When you have completed the Domain Worksheet, transfer the key information from the Domain 
Worksheet to the Internet Agent Clustering Worksheet. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 1: Resource Group for Internet Agent, transfer the disk drive to the Internet Agent 
Clustering Worksheet. 


Under Item 2: Internet Agent Domain Name, transfer the domain name and directory to the Internet 
Agent Clustering Worksheet. 


Planning the Internet Agent Resource Group 


The Internet Agent resource group is similar to the GroupWise resource groups you have already 
set up, as described in “Planning GroupWise Resource Groups” on page 136 and “Creating 
Group Wise Resource Groups” on page 149. The Internet Agent resource group contains a domain 
whose only role is to connect the Internet Agent into your clustered GroupWise system. It also 
contains two agent service resources, one for the MTA that services the domain and one for the 
Internet Agent. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 1: Resource Group for Internet Agent, specify the network name and other required 
information for the Internet Agent resource group. 


To ensure successful short name resolution, add entries for the Internet Agent network name to 
support your preferred methods of short name resolution, as described in “Configuring Short 
Name Resolution” on page 150. 


Planning Cluster-Unique Port Numbers for the Internet Agent and Its MTA 


As with the MTA and the POA, the Internet Agent needs cluster-unique port numbers. As part of 
planning to install the MTA and POA, you should already have determined the resource group IP 
address and cluster-unique port numbers for the Internet Agent and its MTA as you filled out the 
“Network Address Worksheet” on page 146. If you do not have a filled-out copy of this worksheet 
for your system, print it now and fill in current system information. 
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INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 5: MTA Network Information, transfer the resource group IP address and cluster-unique 
port numbers from the Internet Agent section of the Network Address Worksheet to the Internet Agent 
Clustering Worksheet. 


Under Item 7: Internet Agent Network Information, transfer the resource group IP address (the same 
as for its MTA) and the cluster-unique Internet Agent port number from the Internet Agent section of 
the Network Address Worksheet to the Internet Agent Clustering Worksheet. 


Preparing Your Firewall for the Internet Agent 


The Internet Agent will receive incoming messages on the IP address of the Internet Agent 
resource group. Your firewall configuration must be modified to allow inbound TCP/IP traffic 
from the Internet to the Internet Agent IP address on the following standard ports: 


Protocol Standard Port 
IMAP4 143 

LDAP 389 

POP3 110 

SMTP 25 


By default, the Internet Agent will send outgoing messages on the ZP address of the node where it 
is running. If you decide to use this default configuration, your firewall must be configured to 
allow outbound TCP/IP traffic from all nodes on the Internet Agent resource group’s possible 
owners list. 


If the Internet Agent has a large number of nodes in its possible owners list, you could configure 
the Internet Agent to send outgoing messages to a relay host, which would then send them out 
through the firewall using its own IP address rather than the IP address of the particular node where 
the Internet Agent is running. This reduces the amount of modification to your firewall required 
to set up the Internet Agent. However, if the relay host goes down, all outgoing messages would 
be delayed. 


As another alternative, you can configure the Internet Agent to use its resource group IP address 
for sending as well as receiving messages. Setup instructions for this configuration are provided 
in “Forcing Use of the Internet Agent Secondary IP Address” on page 75, which you can complete 
after installing the Internet Agent. 


In preparation for installing the Internet Agent, configure your firewall as needed to handle the 
Internet Agent’s use of node and resource group IP addresses when sending and receiving 
messages. 


Deciding Where to Install the Internet Agent and Its MTA 


The default Internet Agent installation directory is c:\grpwise\gwia. As with the MTA and the 
POA, you can choose to install the Internet Agent and its MTA to each node in the cluster or to the 
shared disk of the Internet Agent resource group. For a discussion of these alternatives, see 
“Deciding Where to Install the Agent Software” on page 141, which describes the issues in the 
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context of planning MTA and POA installations. As with the MTA and POA, the Internet Agent 
and its MTA must be installed as Windows services. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 4: MTA Installation Location and Item 6: Internet Agent Installation Location, mark whether 
you will install the Internet Agent and its MTA to the shared disk of the Internet Agent resource group 
or to each node in the cluster. If necessary, specify where the MTA startup file and the Internet Agent 
configuration file (gwia.cfg) will be stored. 


Planning the MTA Installation 


Follow the instructions in “Planning the Windows Agent Installation” on page 143 to plan the 
MTA installation for the Internet Agent domain, then return to this point. After you follow the 
instructions, you will have a filled-out Windows Agent Worksheet to use when you install the 
MTA. 


IMPORTANT: Do not install the Windows MTA until you are instructed to do so in “Setting Up the Internet 
Agent in a Cluster” on page 164. 


Planning the Internet Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Internet Agent are the same in a Microsoft cluster as for any 
other environment. Review “Installing the Internet Agent Software on NetWare or Windows”, then 
print and fill out the “GroupWise Internet Agent Installation Worksheet” in “Installing the 
GroupWise Internet Agent” in the Group Wise 6.5 Installation Guide. You will need this 
information as you install the Internet Agent in your cluster. 


IMPORTANT: Do not install the Internet Agent software until you are instructed to do so in “Setting Up the 
Internet Agent in a Cluster” on page 164. 


Setting Up the Internet Agent in a Cluster 


You should already have reviewed “Planning the Internet Agent in a Cluster” on page 161 and 
filled out the “Internet Agent Clustering Worksheet” on page 170. You are now ready to complete 
the following tasks to set up the Internet Agent in a Microsoft cluster: 


+ “Setting Up the Internet Agent Resource Group” on page 164 

+ “Creating a Domain for the Internet Agent” on page 165 

+ “Installing the MTA for the Internet Agent Domain” on page 165 

+ “Installing and Configuring the Internet Agent in a Cluster” on page 165 
+ “Testing the Clustered Internet Agent” on page 168 


Setting Up the Internet Agent Resource Group 


164 


1 Create the Internet Agent resource group and agent services resources (Internet Agent 
Clustering Worksheet item 1), as planned in “Planning the Internet Agent Resource Group” 
on page 162. 


2 To ensure successful short name resolution, add entries for the Internet Agent network name 
to support your preferred methods of short name resolution, as described in “Configuring 
Short Name Resolution” on page 150. 
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3 To ensure that the Internet Agent has incoming and outgoing access to the Internet, make sure 
your firewall is properly configured, as described in “Preparing Your Firewall for the Internet 
Agent” on page 163. 


4 Continue with “Creating a Domain for the Internet Agent” on page 68. 


Creating a Domain for the Internet Agent 


The Internet Agent domain will be a secondary domain. To create it, follow the instructions in 
“Creating a New Secondary Domain in a Cluster” on page 152, taking your information from the 
Internet Agent Clustering Worksheet, rather than the System Clustering Worksheet, then return to 
this point. 


Do not create any post offices in the Internet Agent domain. 


Continue with “Installing the MTA for the Internet Agent Domain” on page 165. 


Installing the MTA for the Internet Agent Domain 


The MTA for the Internet Agent domain can be installed just like any other MTA in your clustered 
GroupWise system. Follow the instructions in “Installing the Agent Software in a Cluster” on 
page 155, then return to this point. 


You do not need to edit the MTA startup file. 


Continue with “Installing and Configuring the Internet Agent in a Cluster” on page 165. 


Installing and Configuring the Internet Agent in a Cluster 


After you have created a domain for the Internet Agent and installed the MTA for that domain, you 
are ready to install and configure the Internet Agent. 


+ “Installing and Configuring the Internet Agent in a Cluster” on page 165 
¢ “Enabling Internet Addressing for Your Clustered GroupWise System” on page 166 
+ “Verifying GWIA Object Properties” on page 166 


Installing the Internet Agent Software in a Cluster 


1 Map a drive to the shared disk of the Internet Agent resource group (Internet Agent Clustering 
Worksheet item 1). 


2 Map a drive to c:\ on the first node in the cluster where you will set up the Internet Agent as 
a Windows service (System Clustering Worksheet item 2). 


3 Ifyou plan to install the Internet Agent software to the shared disk of the Internet Agent 
resource group (Internet Agent Clustering Worksheet item 6), create the drive:\grpwise\gwia 
directory on the shared disk accessed in Step 1. 


or 


If you plan to install the Internet Agent software to each node in the cluster, create the 
c:\grpwise\gwia directory on the drive accessed in Step 2). 


4 Start the Internet Agent Installation program, following the steps provided in “Installing the 
Internet Agent Software on NetWare or Windows” in “Installing the Group Wise Internet 
Agent” in the GroupWise 6.5 Installation Guide. 
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5 Install the Windows Internet Agent, keeping in mind the following cluster-specific details: 


+ Use the Windows Internet Agent Clustering Worksheet that you filled out during 
“Planning the Internet Agent Installation” on page 66 to fill in the fields during the 
Internet Agent installation process. 


+ On the Installation Path page, be sure to browse through the mapped drive to the directory 
you created in Step 3 above. Be sure that Run WebAccess Agent as a Windows Service 
is selected. 


+ On the GroupWise Domain page, be sure to browse through the drive you mapped in 
Step 1 to the domain directory on the shared disk. 


+ On the Post Installation Task List page, deselect Launch Internet Agent Now so that the 
Installation program does not start the Internet Agent after installation is complete. 


6 Repeat Step 4 and Step 5, mapping a drive to each node in the cluster. 


Even if you installed the Internet Agent software to a shared disk, you need to repeat the 
installation process for each node so that the Internet Agent gets set up as a Windows service 
on each node. 


7 Ifyou installed the software to each node in the cluster and you selected Yes for Consolidate 
Configuration Files? (under Internet Agent Clustering Worksheet item 6), copy the gwia.cfg 
file to the planned location on the shared disk, then delete it from the c:\grpwise\gwia 
directory on each node to avoid future confusion. 


8 Make sure you have completed all the tasks described in “Installing the GroupWise Internet 
Agent” in the GroupWise 6.5 Installation Guide. 


9 Continue with “Enabling Internet Addressing for Your Clustered GroupWise System” on 
page 166. 


Enabling Internet Addressing for Your Clustered GroupWise System 


Setting up Internet addressing for a clustered Internet Agent is no different from setting it up for 
an Internet Agent in a any other environment. Follow the instructions in “Enabling Internet 
Addressing” in “System” in the GroupWise 6.5 Administration Guide, then continue with 
“Verifying GWIA Object Properties” on page 166. 


Verifying GWIA Object Properties 


During installation of the Internet Agent, the GWIA object should have been configured correctly. 
However, it can be helpful to verify certain cluster-specific information in order to familiarize 
yourself with the configuration of a clustered Internet Agent. 


+ “Accessing GWIA Object Properties” on page 166 

+ “Verifying the Reference to the Network Name for Use by DNS” on page 167 

+ “Verifying the Reference to the Network Name in Directory Paths” on page 167 
¢ “Verifying Post Office Links” on page 167 

+ “Forcing Use of the Internet Agent Resource Group IP Address” on page 167 


Accessing GWIA Object Properties 


4 In ConsoleOne®, browse to and select the Internet Agent domain in order to display its 
contents. 


2 Right-click the GWIA object, then click Properties. 
3 Continue with “Verifying the Reference to the Volume Resource” on page 74. 
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Verifying the Reference to the Network Name for Use by DNS 


In the GWIA object properties pages: 
1 Click SMTP/MIME > Settings. 
2 Verify the contents of the Hostname/DNS "A Record" Name field. 


It displays the hostname as currently configured in DNS. It should match the network name 
of the domain resource group, not the name of a node in the cluster. 


3 Make changes if necessary. 
4 Continue with “Verifying the Reference to the Network Name in Directory Paths” on 
page 167. 


Verifying the Reference to the Network Name in Directory Paths 
In the GWIA object properties pages: 
1 Click Server Directories. 


2 Verify that the displayed directories match the network name of the domain resource group, 
not the name of a node in the cluster. 


3 Make changes if necessary. 


4 Continue with “Verifying Post Office Links” on page 167. 


Verifying Post Office Links 
In the GWIA object properties pages: 
1 Click Post Office Links. 


2 Verify that the Access Mode column displays C/S (for client/server mode) for all post offices 
serviced by the clustered Internet Agent. 


3 Verify that the Links column displays the IP addresses of the post office resource groups, not 
the IP addresses of any nodes in the cluster. 


4 Make changes if necessary. 


5 Continue with “Forcing Use of the Internet Agent Resource Group IP Address” on page 167. 


Forcing Use of the Internet Agent Resource Group IP Address 


If you want the Internet Agent to send outgoing messages on its resource group IP address, rather 
than using the default the node IP address: 


1 Click GroupWise > Network Address. 


2 Inthe TCP/IP Address field, provide the resource group IP address (under Internet Agent 
Clustering Worksheet item 1) for the Internet Agent to use for sending outgoing messages. 


3 Click SMTP/MIME, then click Settings. 

4 Select Bind to TCIP/IP Address at Connection Time. 

5 Click OK. 

6 Continue with “Testing the Clustered Internet Agent” on page 168. 
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Testing the Clustered Internet Agent 


After you have set up the Internet Agent resource group, you can test it by manually bringing it 
online and taking it offline again. 


Continue with “Managing the Internet Agent in a Cluster” on page 168 


Managing the Internet Agent in a Cluster 
After you have installed the Internet Agent in a cluster, you should consider some long-term 
management issues. 
+ “Updating GroupWise Objects with Cluster-Specific Descriptions” on page 168 
+ “Knowing What to Expect in an Internet Agent Failover Situation” on page 169. 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After installing the Internet Agent in your clustered GroupWise system, while the cluster-specific 
information is fresh in your mind, you should record that cluster-specific information as part of the 
Group Wise objects in ConsoleOne® so that you can easily refer to it later. Be sure to update the 
information recorded in the GroupWise objects if the configuration of your system changes. 


+ “Recording Cluster-Specific Information about the Internet Agent Domain and Its MTA” on 
page 168 


è “Recording Cluster-Specific Information about the Internet Agent” on page 168 


Recording Cluster-Specific Information about the Internet Agent Domain and Its MTA 


To permanently record important cluster-specific information for the Internet Agent domain: 
1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 In the Description field of the Internet Agent domain Identification page, provide a cluster- 
specific description of the Internet Agent domain, including its resource group IP address and 
the cluster-unique port numbers used by its MTA. 


Click OK to save the Internet Agent domain description. 
Select the Internet Agent Domain object to display its contents. 


Right-click the MTA object, then click Properties. 


oa bh Ww 


In the Description field of the MTA Identification page, record the domain resource group IP 
address and the cluster-unique port numbers used by the MTA. 


This information will appear on the MTA console, no matter which node in the cluster it is 
currently running on. 


7 Click OK to save the MTA description. 


8 Continue with “Recording Cluster-Specific Information about the Internet Agent” on 
page 168. 


Recording Cluster-Specific Information about the Internet Agent 


With the contents of the Internet Agent domain still displayed: 
1 Right-click the GWIA object, then click Properties. 
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2 Click GroupWise, then click Identification. 


3 In the Description field, record the resource group IP address and the cluster-unique port 
numbers used by the Internet Agent. 


This information will appear on the Internet Agent console, no matter which node in the 
cluster it is currently running on. 


4 Click OK to save the Internet Agent information. 


5 Continue with “Knowing What to Expect in an Internet Agent Failover Situation” on 
page 169. 


Knowing What to Expect in an Internet Agent Failover Situation 


The failover behavior of the MTA for the Internet Agent domain will be the same as for an MTA 
in a regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on 
page 158. 


Failover of the Internet Agent itself is more complex. The various e-mail clients (POP3, IMAP4, 
and LDAP) will receive an error message when the server they were connected to becomes 
unavailable. Most of the clients do not attempt to reconnect automatically, so the user must exit the 
e-mail client and restart it to reestablish the connection after the failover process is complete. 
Fortunately, the Internet Agent restarts quickly in its failover location so users will be able to 
reconnect quickly. 


As with the MTA and the POA, manual migration of the Internet Agent takes longer than failover. 
In fact, the Internet Agent can seem especially slow to shut down properly, as it finishes its normal 
processing and stops its threads. For a busy Internet Agent, you might need to wait several minutes 
for it to shut down properly when you are manually migrating it. 
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Internet Agent Clustering Worksheet 


Item 


1) Resource Group for Internet Agent: 
Network name: 
IP address: 
Physical disk: 
File share: 
MTA service resource: 
Internet Agent service resource: 
Possible owners: 


2) Internet Agent Domain Name: 
Domain Directory: 


4) MTA Installation Location: 


¢ Shared disk of the Internet Agent 
resource group 


+ Each node in the cluster 
Consolidate MTA startup files? 


5) MTA Network Information: 
MTA IP address: 
MTA message transfer port: 
MTA live remote port: 
MTA HTTP port 


6) Internet Agent Installation Location: 


¢ Shared disk in the Internet Agent 
resource group 


+ Each node in the cluster 


Consolidate configuration files? 


7) Internet Agent Network Information: 
Internet Agent IP address: 
Internet Agent HTTP port: 


Explanation 


Specify the information for the Internet Agent resource group. 


For more information, see “Planning the Internet Agent Resource Group” on 
page 162. 


Specify a unique name for the Internet Agent domain. Specify the directory on the 
physical disk that belongs to the Internet Agent resource group where you want to 
create the new domain. 


For more information, see “Planning a Domain for the Internet Agent” on page 162. 


Mark the location where you will install the MTA software. If necessary, specify the 
location where you will consolidate the MTA startup files from the various nodes 
where the Internet Agent is installed. 


For more information, see “Deciding Where to Install the Internet Agent and Its MTA” 
on page 163. 


Gather the MTA network address information from the Internet Agent section of the 
“Network Address Worksheet” on page 146. 


For more information, see “Planning Cluster-Unique Port Numbers for the Internet 
Agent and Its MTA” on page 162. 


Mark the location where you will install the Internet Agent software. 


If necessary, specify the location on the shared disk of the Internet Agent resource 
group where you will consolidate the Internet Agent configuration files (gwia.cfg) from 
the various nodes where it is installed. 


For more information, see “Deciding Where to Install the Internet Agent and Its MTA” 
on page 163. 


Gather the Internet Agent network address information from the Internet Agent 
section of the “Network Address Worksheet” on page 146. 


For more information, see “Planning Cluster-Unique Port Numbers for the Internet 
Agent and Its MTA” on page 162. 
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Implementing WebAccess in a Microsoft Cluster 


You should already have set up at least a basic GroupWise® system, as described in Chapter 13, 
“Planning Group Wise in a Microsoft Cluster,” on page 133 and Chapter 14, “Setting Up a Domain 
and Post Office in a Microsoft Cluster,” on page 149. As part of this process, the “System 
Clustering Worksheet” on page 144 and the “Network Address Worksheet” on page 146 were 
filled out. If you do not have access to the filled-out worksheets, print the worksheets now and fill 
in the clustering and network address information as it currently exists on your system. You will 
need this information as you implement WebAccess in a cluster. 


+ “Understanding the WebAccess Components” on page 171 
+ “Planning WebAccess in a Cluster” on page 171 

+ “Setting Up WebAccess in a Cluster” on page 175 

+ “Managing WebAccess in a Cluster” on page 178 

+ “WebAccess Clustering Worksheet” on page 181 


Understanding the WebAccess Components 


If you are not familiar with GroupWise WebAccess, review “GroupWise WebAccess Overview” 
in “Installing GroupWise WebAccess” in the GroupWise 6.5 Installation Guide. 


As you plan WebAccess in a clustering environment, you must keep in mind that you will plan and 
set up two separate WebAccess components: 


+ WebAccess Agent (gwinter.exe) that will be associated with a GroupWise WebAccess domain 


+ WebAccess Application (a Java* servlet) that will be added to your Web server 


Planning WebAccess in a Cluster 


A main system configuration difference between a GroupWise system in a clustering environment 
and a GroupWise system in a regular environment is that you need to create a separate domain to 
house each GroupWise gateway, including the WebAccess Agent. The WebAccess Agent is faster 
and more stable when it runs on the same server with its domain. In a cluster, creating a separate 
domain for the WebAccess Agent ensures that the WebAccess Agent and its domain always fail 
over together. 


The “WebAccess Clustering Worksheet” on page 181 lists all the information you will need as you 
set up the WebAccess Agent and the WebAccess Application in a clustering environment. You 
should print the worksheet and fill it out as you complete the tasks listed below: 


+ “Setting Up the Netscape Enterprise Web Server for NetWare in a Cluster on NetWare 6” on 
page 84 


+ “Planning a New Domain for the WebAccess Agent” on page 172 
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+ “Planning the WebAccess Resource Group” on page 173 

+ “Planning Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 173 
+ “Deciding Where to Install the WebAccess Agent and Its MTA” on page 173 

+ “Planning the MTA Installation” on page 174 

+ “Planning the WebAccess Installation” on page 174 


Setting Up Your Web Server in the Microsoft cluster 


Before you install WebAccess, your Web server must already be set up and running in the cluster. 
Make sure that it can fail over and fail back successfully. 


As you set up your Web server, record the following key configuration information on the 
WebAccess Clustering Worksheet: 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 7: Physical Web Servers, list the nodes in the cluster where you are installing the Web 
server software. 


Under Item 8: Web Server IP Address, record the secondary IP address of the Web server resource 
that you create. 


Under Item 9: Hardware Virtual Server Information, record the dedicated IP address for the Web site 
and the document root directory. 


Because the WebAccess Application will be installed to a subdirectory of the Web server 
installation directory (directory\com\novell\webaccess), the WebAccess Application cannot be 
installed on a shared disk. Instead, you will install it to each node in the cluster where the Web 
server has been installed. 


Planning a New Domain for the WebAccess Agent 


The considerations involved in planning a domain for the WebAccess Agent are much the same as 
planning any other domain. In preparation, review “Planning a New Domain”, then print and fill 
out the “Domain Worksheet” in “Domains” in the GroupWise 6.5 Administration Guide. 


Keep in mind the following cluster-specific details: 


+ When you specify the location for the domain directory on the Domain Worksheet, include 
the physical disk in your shared disk system where you want the domain directory to be 
located. 


+ Do not concern yourself with the GroupWise agent information on the Domain Worksheet. 
You can stop with item 10. You will plan the MTA installation later. 


When you have completed the Domain Worksheet, transfer the key information from the Domain 
Worksheet to the WebAccess Clustering Worksheet. 
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WEBACCESS CLUSTERING WORKSHEET 


Under Item 1: Resource Group for WebAccess Agent, transfer the shared disk from the Domain 
Worksheet to the WebAccess Clustering Worksheet. 


Under Item 2: WebAccess Agent Domain Name, transfer the domain name and directory from the 
Domain Worksheet to the WebAccess Clustering Worksheet. 


Planning the WebAccess Resource Group 


The WebAccess resource group is similar to the domain and post office resource groups you have 
already set up, as described in “Planning Group Wise Resource Groups” on page 136 and “Creating 
GroupWise Resource Groups” on page 149. The WebAccess resource group contains a domain 
whose only role is to connect the WebAccess Agent into your clustered Group Wise system. It also 
contains two agent service resources, one for the MTA that services the domain and one for the 
WebAccess Agent. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 1: Resource Group for WebAccess, specify the network name and other required 
information for the WebAccess resource group. 


To ensure successful short name resolution, add entries for the WebAccess network name to 
support your preferred methods of short name resolution, as described in “Configuring Short 
Name Resolution” on page 150. 


Planning Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA 


As with the MTA and the POA, the WebAccess Agent needs cluster-unique port numbers. As part 
of planning to install the MTA and POA, you should already have determined the IP address and 
cluster-unique port numbers for the WebAccess Agent and its MTA as you filled out the “Network 
Address Worksheet” on page 146. If you do not have a filled-out copy of this worksheet for your 
system, print it now and fill in current system information. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 1: Resource Group for WebAccess, transfer the WebAccess resource group IP address. 


Under Item 4: MTA Network Information, transfer the cluster-unique MTA port numbers from the 
WebAccess section the Network Address Worksheet to the WebAccess Clustering Worksheet. 


Under Item 6: WebAccess Agent Network Information, transfer the cluster-unique WebAccess Agent 
port number from the WebAccess section of the Network Address Worksheet to the WebAccess 
Clustering Worksheet. 


Deciding Where to Install the WebAccess Agent and Its MTA 


As with the MTA and the POA, you can choose to install the WebAccess Agent and its MTA to 
each node in the cluster or to the shared disk of the WebAccess resource group. For a discussion 
of these alternatives, see “Deciding Where to Install the Agent Software” on page 141, which 
describes the issues in the context of planning MTA and POA installations. 
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WEBACCESS CLUSTERING WORKSHEET 


Under Item 3: MTA Installation Location and Item 5: WebAccess Agent Installation Location, mark 
whether you will install the WebAccess Agent and its MTA to each node in the cluster or to the shared 
disk of the WebAccess resource group. Also specify where the MTA startup file will be stored. 


Planning the MTA Installation 


Follow the instructions in “Planning the MTA Installation” on page 174, then return to this point. 


After you follow the instructions, you will have a filled-out Windows Agent Worksheet to use 
when you install the MTA. 


IMPORTANT: Do not install the Windows MTA until you are instructed to do so in “Setting Up WebAccess in 
a Cluster” on page 175. 


Planning the WebAccess Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install WebAccess are the same in a clustering environment as for any other 
environment. Review “Planning GroupWise WebAccess”, then print and fill out the “GroupWise 
WebAccess Installation Worksheet” in “Installing GroupWise WebAccess” in the GroupWise 6.5 
Installation Guide. When you set up WebAccess in a cluster, you will install the WebAccess Agent 
and the WebAccess Application in two separate steps: 


+ “Planning the WebAccess Agent Installation” on page 174 
+ “Planning the WebAccess Application Installation” on page 174 


IMPORTANT: Do not install the WebAccess software until you are instructed to do so in “Setting Up 
WebAccess in a Cluster” on page 175. 


Planning the WebAccess Agent Installation 


For the WebAccess Agent, fill out items 2 through 12 on the GroupWise WebAccess Installation 
Worksheet, taking into account the following cluster-specific issues: 


WEBACCESS INSTALLATION WORKSHEET 


Under Item 2: Installation Directory, take into account your decision recorded on the WebAccess 
Clustering Worksheet (Item 5: WebAccess Agent Installation Location). 


Under Item 3: Server Address, transfer the IP address and port number from the WebAccess 
Clustering Worksheet (Item 6: WebAccess Agent Network Information) filled out during “Planning 
Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 173. 


Under Item 5: Domain Directory Path, transfer the domain directory from the Domain Worksheet you 
filled out during “Planning a New Domain for the WebAccess Agent” on page 172. 


Planning the WebAccess Application Installation 


For the WebAccess Application, fill out items 13 through 19 on the GroupWise WebAccess 
Installation Worksheet, taking into account the following cluster-specific issues: 
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WEBACCESS INSTALLATION WORKSHEET 


Under Item 13: Web Server Type and Root Directory, mark the Web server you have installed in your 
cluster and specify the Web server root directory. 


Under Item 16: Novell Root Directory, specify a directory on the Web server where you want to install 
the WebAccess Agent configuration file. the default is c:\novell 


Setting Up WebAccess in a Cluster 


You should already have reviewed “Planning Group Wise in a Microsoft Cluster” on page 133 and 
filled out the “WebAccess Clustering Worksheet” on page 181. You are now ready to complete the 
following tasks to set up the WebAccess Agent in a clustering environment: 


+ “Setting Up the WebAccess Resource Group” on page 175 

+ “Creating a Domain for the WebAccess Agent” on page 89 

¢ “Installing the MTA for the WebAccess Agent Domain” on page 89 

+ “Installing and Configuring the WebAccess Agent in a Cluster” on page 89 

+ “Installing and Configuring the WebAccess Application in a Cluster” on page 95 
+ “Testing Your Clustered WebAccess Installation” on page 96 


+ “Managing WebAccess in a Cluster” on page 96 


Setting Up the WebAccess Resource Group 


1 Create the WebAccess resource group and agent services resources (WebAccess Clustering 
Worksheet item 1), as planned in “Planning the WebAccess Resource Group” on page 173. 


2 To ensure successful short name resolution, add entries for the WebAccess Agent network 
name to support your preferred methods of short name resolution, as described in 
“Configuring Short Name Resolution” on page 150. 


3 Continue with “Creating a Domain for the WebAccess Agent” on page 175. 


Creating a Domain for the WebAccess Agent 


The WebAccess Agent domain will be a secondary domain. To create it, follow the instructions in 
“Creating a New Secondary Domain in a Cluster” on page 152, taking your information from the 
WebAccess Clustering Worksheet, rather than the System Clustering Worksheet, then return to this 
point. 


Do not create any post offices in the WebAccess Agent domain. 


Continue with “Installing the MTA for the WebAccess Agent Domain” on page 175. 


Installing the MTA for the WebAccess Agent Domain 


The MTA for the WebAccess Agent domain can be installed just like any other MTA in your 
clustered GroupWise system. Follow the instructions in “Installing the Agent Software in a 
Cluster” on page 155, then return to this point. 


You do not need to edit the MTA startup file. 


Continue with “Installing the WebAccess Agent in a Cluster” on page 176. 


Implementing WebAccess in a Microsoft Cluster 175 


Installing the WebAccess Agent in a Cluster 


After you have created a domain for the WebAccess Agent and installed the MTA for that domain, 
you are ready to install and configure the WebAccess Agent. The WebAccess Agent is the 
component of your WebAccess installation that accesses post offices and libraries to retrieve 
information for WebAccess client users. 


1 Map a drive to the shared disk of the WebAccess resource group (WebAccess Clustering 
Worksheet item 1). 


2 Map a drive to c:\ on the first node in the cluster where you will set up the WebAccess Agent 
as a Windows service (System Clustering Worksheet item 2). 


3 Ifyou plan to install the WebAccess Agent software to the shared disk of the WebAccess 
resource group (WebAccess Clustering Worksheet item 5), create the drive:\grpwise\webacc 
directory on the WebAccess shared disk accessed in Step 1. 


or 


If you plan to install the WebAccess Agent software to each node in the cluster, create the 
c:\grpwise\webacc directory on the drive accessed in Step 2. 


4 Start the WebAccess Installation program, following the steps provided in “Installing the 
WebAccess Agent” in “Installing GroupWise WebAccess” in the GroupWise 6.5 Installation 
Guide. 


5 Install the Windows WebAccess Agent, keeping in mind the following cluster-specific details: 
+ On the Components page select only GroupWise WebAccess Agent. 
Do not install the WebAccess Application at this time. 


+ Use items 2 through 12 on the GroupWise WebAccess Installation Worksheet that you 
filled out during “Planning the WebAccess Installation” on page 174 to fill in the fields 
during the WebAccess Agent installation process. 


+ On the Installation Path page, be sure to browse through the mapped drive to the 
installation directory you created in Step 3 above. 


+ On the Gateway Directory page, be sure to browse to the domain directory through the 
drive you mapped in Step | above. 


+ On the Execution Options page, be sure that Run WebAccess Agent as a Windows 
Service is selected. 


+ On the Start Applications page, deselect Start the GroupWise WebAccess Agent. 
6 Repeat Step 4 and Step 5, mapping a drive to each node in the cluster. 


Even if you installed the WebAccess Agent software to a shared disk, you need to repeat the 
installation process for each node so that the Internet Agent gets set up as a Windows service 
on each node. 


7 Make sure you have completed all the WebAccess Agent tasks described in “Setting Up 
GroupWise WebAccess on NetWare or Windows” in “Installing GroupWise WebAccess” in 
the GroupWise 6.5 Installation Guide, but do not start the WebAccess Agent at this time. 


8 Continue with “Installing and Configuring the WebAccess Application in a Cluster” on 
page 177. 
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Installing and Configuring the WebAccess Application in a Cluster 


Recall that the WebAccess Agent is the component of your WebAccess installation that accesses 
post offices and libraries to retrieve information for WebAccess client users. The WebAccess 
Application provides the link between the WebAccess Agent and the WebAccess clients’ Web 
browsers. 


To install the WebAccess Application: 


1 Map a drive to the shared disk of the WebAccess resource group (WebAccess Clustering 
Worksheet item 1) where the WebAccess domain is located. 


2 Map adrive to the first Web server node where you want to install the WebAccess Application 
(WebAccess Clustering Worksheet item 7). 


3 Ifthe Web server node where you are going to install the WebAccess Application is currently 
running any applications that rely on Java or on the Web server, migrate those applications to 
another node in the cluster. If any GroupWise agents are running on the node, migrate the 
agents. 


4 Stop the Web server. 


5 Start the WebAccess Installation program as you did when you installed the WebAccess Agent 
(Step 5 on page 176). Keep in mind the following cluster-specific details: 


+ On the Components page, select only GroupWise WebAccess Application. 


+ Use items 13 through 19 on the GroupWise WebAccess Installation Worksheet that you 
filled out during “Planning the WebAccess Installation” on page 174 to fill in the fields 
during the WebAccess Application installation process. 


+ On the Gateway Directory page, be sure to browse to the WebAccess gateway directory 
(domain\wpgate\webac60a) through the drive you mapped in Step | above. 


+ On the Web Server Information page be sure to browse to the Web server root directory 
through the drive you mapped in Step 2 above. 


+ On the Start Applications page, deselect Restart Web Server. 


6 Make sure you have completed all the WebAccess Application tasks described in “Setting Up 
GroupWise WebAccess on NetWare or Windows” in “Installing GroupWise WebAccess” in 
the GroupWise 6.5 Installation Guide. 


7 Copy the directory\docs\com directory from the server where you just installed the 
WebAccess Application to the document root directory of the Web server (WebAccess 
Clustering Worksheet item 13). 


8 Restart the Web server. 
9 Offline and then online the Web server to reestablish its resource group IP address. 


10 Repeat Step 2 through Step 9 for each Web server node in the Web server resource group 
possible owners list (WebAccess Clustering Worksheet item 1). 


11 Continue with “Testing Your Clustered WebAccess Installation” on page 177. 


Testing Your Clustered WebAccess Installation 


Remember that the WebAccess resource group and the Web server resource group are separate 
resource groups that could fail over to different nodes at different times. 


To thoroughly test your WebAccess installation: 
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4 
5 


Make sure the initial combination of WebAccess resource group and Web server resource 
group is functioning properly. 


Migrate the WebAccess resource group to each node in its possible owners list, making sure 
it functions with the initial Web server node. 


Migrate the Web server to a different node, migrate the WebAccess resource group to each 
node in its possible owners list, then make sure each combination works. 


Repeat Step 3 for each Web server resource group. 


Continue with “Managing WebAccess in a Cluster” on page 178. 


Managing WebAccess in a Cluster 


After you have installed WebAccess in a cluster, you should consider some long-term management 
issues. 


+ 


+ 


+ 


“Updating GroupWise Objects with Cluster-Specific Descriptions” on page 178 
“Knowing What to Expect in WebAccess Failover Situations” on page 179 
“Updating the WebAccess Agent Configuration File (commgr.cfg)” on page 179 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After installing WebAccess in your clustered GroupWise system, while the cluster-specific 
information is fresh in your mind, you should record that cluster-specific information as part of the 
GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the 
information recorded in the GroupWise objects if the configuration of your system changes. 


+ 


+ 


“Recording Cluster-Specific Information about the WebAccess Agent Domain and Its MTA” 
on page 178 


“Recording Cluster-Specific Information about the WebAccess Agent” on page 179 


Recording Cluster-Specific Information about the WebAccess Agent Domain and Its MTA 


To permanently record important cluster-specific information for the WebAccess Agent domain: 


1 
2 


og bh @ 


In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


In the Description field of the WebAccess Agent domain Identification page, provide a 
cluster-specific description of the WebAccess Agent domain, including the resource group IP 
address and the cluster-unique port numbers used by its MTA. 


You might also want to include cluster-specific information about the WebAccess 
Application, such as the resource group IP address of the Web server where the WebAccess 
Application is installed. 


Click OK to save the WebAccess domain description. 
Select the WebAccess Domain object to display its contents. 
Right-click the MTA object, then click Properties. 


In the Description field of the MTA Identification page, record the WebAccess resource group 
IP address and the cluster-unique port numbers used by the MTA. 


This information will appear on the MTA console, no matter which node in the cluster it is 
currently running on. 
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7 Click OK to save the MTA description. 
8 Continue with “Recording Cluster-Specific Information about the WebAccess Agent” on 
page 179. 
Recording Cluster-Specific Information about the WebAccess Agent 
With the contents of the WebAccess domain still displayed: 
1 Right-click the WEBAC65A object, then click Properties. 
2 Click GroupWise > Identification. 


3 In the Description field, record the WebAccess resource group IP address and the cluster- 
unique port numbers used by the WebAccess Agent. 


This information will appear on the WebAccess Agent console, no matter which node in the 
cluster it is currently running on. 


4 Click OK to save the WebAccess Agent information. 


5 Continue with “Knowing What to Expect in WebAccess Failover Situations” on page 179. 


Knowing What to Expect in WebAccess Failover Situations 


The failover behavior of the MTA for the WebAccess domain will be the same as for an MTA in 
a regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on 
page 158. 


The WebAccess Application caches users’ credentials on the node where it is running. Therefore, 
if that node fails, or if the WebAccess Application migrates to a different node, the cached 
credentials are lost. Consequently, the user will need to restart the WebAccess client in order to re- 
authenticate and re-establish the credentials. 


If the WebAccess Agent fails over or migrates, the user receives an error message that the 
WebAccess Agent is no longer available. However, after the WebAccess Agent starts in its new 
location, the WebAccess Application passes the cached user credentials to the WebAccess Agent 
and the user reconnects automatically without having to re-authenticate. 


As with the MTA and the POA, migration of the WebAccess Agent takes longer than failover. 
However, the WebAccess Agent restarts quickly so that users are able to reconnect quickly. 


Updating the WebAccess Agent Configuration File (commgr.cfg) 


As part of installing WebAccess, the WebAccess Agent configuration file (commer.cfg) is created 
in the following subdirectory: 


domain\wpgate\webac65a 
It is also automatically copied to the following Web server subdirectory: 
drive:\novell\webaccess 


If you change WebAccess agent configuration information (for example, if you change its IP 
address), the information is changed in the following file: 


domain\wpgate\webac65a\commer.cfg 


because the domain is on the shared disk of a resource group, and it is changed in the following file: 
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drive:\novell\webaccess\commer.cfg 


on the node where the WebAccess Application is currently running. However, the other nodes in 
the Web server possible owners list are not currently available for update. Therefore, you must 
manually copy the updated commegr.cfg file to the drive:\novell\webaccess subdirectory on each 
node in the Web serve possible owners list. 
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WebAccess Clustering Worksheet 


Item 


1) Resource Group for WebAccess 
Agent: 


Group name: 

Network name: 

IP address: 

Shared disk: 

Share name: 

MTA service resource: 

WebAccess Agent service resource: 
Possible owners: 


2) WebAccess Agent Domain Name: 


Domain Directory: 


3) MTA Installation Location: 


+ Shared disk of WebAccess resource 
group 


+ Each node in the cluster 
Consolidate MTA startup files? 


4) MTA Network Information: 


MTA IP address: 

MTA message transfer port: 
MTA live remote port: 

MTA HTTP port: 


5) WebAccess Agent Installation 
Location: 


+ Shared disk of WebAccess resource 
group 


+ Each node in the cluster 


6) WebAccess Agent 
Network Information: 


WebAccess Agent IP address: 
WebAccess Agent HTTP port: 


7) Physical Web Servers: 


Explanation 


Specify the information for the WebAccess resource group. 


For more information, see “Planning the WebAccess Resource Group” on page 173. 


Specify a unique name for the WebAccess Agent domain. Specify the directory on 
the WebAccess Agent resource group disk where you want to create the new 
domain. 


For more information, see “Planning a New Domain for the WebAccess Agent” on 
page 172. 


Mark the location where you will install the MTA software. 


If necessary, specify the location where you will consolidate the MTA startup files on 
the shared disk of the WebAccess resource group. 


For more information, see “Deciding Where to Install the WebAccess Agent and Its 
MTA” on page 173. 
Gather the MTA network address information from the WebAccess section of the 


“Network Address Worksheet” on page 146. 


For more information, see “Planning Cluster-Unique Port Numbers for the 
WebAccess Agent and Its MTA” on page 173. 


Mark the location where you will install the WebAccess Agent software. 


For more information, see “Deciding Where to Install the WebAccess Agent and Its 
MTA” on page 173. 


Gather the WebAccess Agent network address information from the WebAccess 
section of the “Network Address Worksheet” on page 146. 


For more information, see “Planning Cluster-Unique Port Numbers for the 
WebAccess Agent and Its MTA” on page 173. 


List the servers in the cluster where you are installing the Web server for use with 
WebAccess. 


For more information, see “Setting Up Your Web Server in the Microsoft cluster” on 
page 172. 
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Item Explanation 


8) Web Server Record the secondary IP address for the Web server in the cluster. 


IP Address: 
For more information, see “Setting Up Your Web Server in the Microsoft cluster” on 


page 172. 


9) Hardware Virtual Server Information: Record the hardware virtual server information for your shared disk system. 


+ Dedicated IP address: For more information, see “Setting Up Your Web Server in the Microsoft cluster” on 


+ Document root page 172. 
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Implementing GroupWise Gateways in a 
Microsoft Cluster 


A significant system configuration difference between a GroupWise® system in a clustering 
environment and a Group Wise system in a regular environment is that you need to create a separate 
domain to house each GroupWise gateway. The gateway domain should be created in its own 
resource group. This enables the gateway to fail over independently from other GroupWise 
components. 


If you have set up the Internet Agent or WebAccess in your clustered GroupWise system, you 
should already have the skills necessary to set up a GroupWise gateway as well. 


Group Wise gateways that have not received recent development have not been thoroughly tested 
in a clustering environment. If you are currently using such GroupWise gateways, you might want 
to leave them outside of your cluster. 
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Monitoring a GroupWise System in a Microsoft 
Cluster 


GroupWise® Monitor is similar to WebAccess in that it relies on a Web server for communication 
with administrators’ Web browsers. Consequently, the setup procedure for GroupWise Monitor in 
a Microsoft cluster is similar to the setup procedure for WebAccess. If you have set up WebAccess 
in your clustered GroupWise system, you should already have the skills necessary to set up 
GroupWise Monitor as well. 


When you first install Monitor, it gathers information about agents to monitor from a domain 
database (wpdomain.db). This provides the resource group IP address of each agent. When an 
agent fails over or migrates to a different node, its status in Monitor displays as Not Listening until 
it is up and running again, at which time its status returns to Normal. 


Because Monitor must use resource group IP addresses to monitor the agents in a clustered 
GroupWise system, the Discover Machine and Discover Network options do not work in a cluster. 
Resource group IP addresses cannot be obtained by examining the network itself. If you need to 
add agents to monitor, use the Add Agent option and provide the agent’s resource group IP address. 


For instructions on setting up GroupWise Monitor, see “Installing GroupWise Monitor” in the 
GroupWise 6.5 Installation Guide. 
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Backing Up a GroupWise System in a Microsoft 
Cluster 


The issues involved in backing up a GroupWise” system in a Microsoft cluster are the same as in 
backing up any GroupWise system that is running on Windows. If you want to back up your 
Group Wise system while it is running, you must use backup software that can back up open files. 
If your backup software cannot back up open files, then you must stop all GroupWise agents before 
running the backup and start them again when the backup is finished. This means that Group Wise 
users cannot be logged into their mailboxes while backups are running. 
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Moving an Existing GroupWise 6.5 System into 
a Microsoft Cluster 


If you are adding the high availability benefits of a Microsoft cluster to a GroupWise” 6.5 system 
that is already up and running, the first step is to set up the cluster and review Chapter 12, 
“Introduction to Group Wise 6.5 and Microsoft Clusters,” on page 131 to help you apply clustering 
principles and practices to your GroupWise system. 


You do not need to transfer your entire GroupWise system into the cluster all at once. You could 
transfer individual post offices where the needs for high availability are greatest. You could 
transfer a domain and all of its post offices at the same time. You might decide that you don’t need 
to have all of your GroupWise system running in the cluster. 


This section provides a checklist to help you get started with moving your Group Wise system into 
a Microsoft cluster: 


m) 


m) 


(E 


m) 


Decide which shared disks you will use for GroupWise administration (ConsoleOne® and the 
software distribution directory). 


Decide which shared disks you will use for GroupWise domains and post offices. 
Plan the resource groups for domains and post offices. 


Review Chapter 13, “Planning GroupWise in a Microsoft Cluster,” on page 133. Fill out the 
“System Clustering Worksheet” on page 144 to help you decide which domains and post 
offices you will move to which shared disks. 


Review “Planning Cluster-Unique Port Numbers for Agents in the Cluster” on page 139 and 
fill out the “Network Address Worksheet” on page 146 to record resource group IP addresses 
and to specify cluster-specific port numbers for all of your GroupWise agents. 


Select the first shared disk that will be part of your clustered GroupWise system and set up the 
resource group for it, following the instructions in “Creating GroupWise Resource Groups” 
on page 149 and “Configuring Short Name Resolution” on page 150. 


Move a domain and/or post office onto the shared disk, following the instructions in “Moving 
a Domain” in “Domains” or “Moving a Post Office” in “Post Offices” in the GroupWise 6.5 
Administration Guide. 


Review “Deciding How to Install and Configure the Agents in a Cluster” on page 139, fill out 
the “Agent Clustering Worksheet” on page 147, and install the agents as needed for the first 
clustered domain and/or post office, following the instructions in “Installing and Configuring 
the MTA and the POA in a Cluster” on page 154. 


Test the first component of your clustered GroupWise system following the instructions in 
“Testing Your Clustered GroupWise System” on page 156. 


Take care of the cluster management details described in “Managing Your Clustered 
GroupWise System” on page 157. 
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Q Move more domains and post offices into the cluster as needed. If you have GroupWise 
libraries, see “Planning a Library for a New Clustered Post Office” on page 135. 


QO) Move GroupWise administration into the cluster as needed. 


QO) Add other components to your clustered GroupWise system as needed, following the 
instructions in: 


+ Chapter 15, “Implementing the Internet Agent in a Microsoft Cluster,” on page 161 

+ Chapter 16, “Implementing WebAccess in a Microsoft Cluster,” on page 171. 

+ Chapter 17, “Implementing GroupWise Gateways in a Microsoft Cluster,” on page 183 
¢ Chapter 18, “Monitoring a GroupWise System in a Microsoft Cluster,” on page 185 

+ Chapter 19, “Backing Up a GroupWise System in a Microsoft Cluster,” on page 187 
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Implementing Messenger in a Microsoft Cluster 


Novell® Messenger does not require the existence of a GroupWise® system in your Microsoft 
cluster, but presumably one has already been set up as described in Chapter 13, “Planning 

Group Wise in a Microsoft Cluster,” on page 133 and Chapter 14, “Setting Up a Domain and Post 
Office in a Microsoft Cluster,” on page 149. As part of the process of setting up GroupWise in your 
cluster, you filled out the “System Clustering Worksheet” on page 144. Some of the information 
from this worksheet will be helpful as you implement Messenger in your cluster. 


+ “Planning Your Messenger System in a Cluster” on page 191 
¢ “Setting Up Your Messenger System in a Cluster” on page 194 
+ “Messenger Clustering Worksheet” on page 196 


Planning Your Messenger System in a Cluster 


Because the Messenger agents are not associated with GroupWise domains or post offices, the 
Messenger agents are easier to implement in a cluster than are the GroupWise agents. The 
“Messenger Clustering Worksheet” on page 196 lists all the information you will need as you set 
up the Messenger agents in a clustering environment. You should print the worksheet and fill it out 
as you complete the tasks listed below: 


+ “Understanding Your Cluster” on page 191 

+ “Planning Messenger Administration” on page 191 

+ “Deciding Where to Install the Messenger Agent Software” on page 192 
+ “Planning the Messenger Agent Installation” on page 193 


Understanding Your Cluster 


Fill out items 1 and 2 on the “Messenger Clustering Worksheet’ on page 196 with information 
about your cluster. This information corresponds to items 1 and 2 on the “System Clustering 
Worksheet” on page 144 that you filled out for GroupWise. For background information, see 
“Setting Up Your Microsoft Cluster” on page 134. 


Planning Messenger Administration 


If you have set up a shared disk for GroupWise administration, as described in “Planning Shared 
Administrative Resources” on page 137, you can use the same shared disk for the Messenger 
administration files. For example, you might want to have a shared disk where you install the 
Messenger snap-in to ConsoleOne® instead of installing it to multiple administrator workstations. 
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MESSENGER CLUSTERING WORKSHEET 


Under Item 5: Installation Location for Messenger Administration, mark whether you want to install the 
Messenger snap-in to ConsoleOne to administrator workstations or to a shared disk. 


If you plan to install the Messenger snap-in to ConsoleOne to a shared disk, under Item 6: Resource 
for Messenger Administration, list the network name and IP address of the shared disk, the physical 
disk name and file share for mapping to it, and the nodes in the cluster that it could fail over to. 


Deciding Where to Install the Messenger Agent Software 


In a Microsoft cluster, the Messenger agents must run as Windows services. When you install the 
Windows Messenger Agents, you can choose between two different installation locations: 


Location Description 

Each node in the The c:\novell\nm directory is the default installation location provided by the 
cluster Messenger Installation program. 

Shared disk If you create a drive:\novell\nm directory on a shared disk, the Messenger agent 


software and startup files fail over and back along with supporting files such as 
the Messenger archive. 


IMPORTANT: You must install to a shared disk if you do not want a separate 
Messenger archive to be created on each node where the Archive Agent runs. 
If you do not want to use a shared disk, you should plan to install the Archive 
Agent separately outside the cluster. 


Because the Messenger agents must be installed as Windows services in a Microsoft cluster, you 
must initially run the Messenger Installation program for each node in the cluster so that the 
Windows services for the agents get created, regardless of where you are planning to run the 
Messenger agents from. However, for updates, you need to run the Messenger Installation program 
only once if you are running the Messenger agents from a shared disk. 


MESSENGER CLUSTERING WORKSHEET 


Under Item 3: Installation Location for Messenger Agents, mark whether you want to install the 
Messenger agent software to each node in the cluster or to a shared disk. 


Continue with the planning instructions for the installation location you want to use: 
+ “Planning the Messenger Agents on Each Node in the Cluster” on page 192 
¢ “Planning the Messenger Agents on a Shared Disk” on page 193 


Planning the Messenger Agents on Each Node in the Cluster 


Make sure you have filled out item 20n the Messenger Clustering Worksheet with a complete list 
of nodes in the cluster where you need to install the Messenger agents. Continue with “Planning 
the Messenger Agent Installation” on page 193. 
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Planning the Messenger Agents on a Shared Disk 


If you do not anticipate a large Messenger archive, you can use one Messenger shared disk. If you 
anticipate archiving a large number of messages so that the Messenger archive grows very large, 
you might want to have a separate Messenger shared disk for the Archive Agent and the archive 
database. The steps in this section cover setting up the Messenger agents on a single shared disk. 


MESSENGER CLUSTERING WORKSHEET 


Under Item 4: Resource Group for Messenger Agents, plan the network name and IP address of the 
resource group, the physical disk and share name for mapping to it, the agent service names, and the 
nodes in the cluster where the Messenger resource group can fail over. 


Continue with “Planning the Messenger Agent Installation” on page 193. 


Planning the Messenger Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Messenger agents are the same in a clustering environment as 
for any other environment. Review “Planning Your Novell Messenger System”, then print and fill 
out the “Novell Messenger System Worksheet” in “Installing a Novell Messenger System” in the 
Messenger 1.0 Installation Guide. Transfer the following information from the Messenger 
Clustering Worksheet to the Messenger System Worksheet: 


¢ For Item 3: Installation Path on the Messenger System Worksheet: 
¢ If you are installing the Messenger agents to each node in the cluster, use c:\novell\nm. 


¢ If you are installing the Messenger agents to a shared disk, use drive:\novell\nm where 
drive is the shared disk from Item 4: Resource Group for Messenger Agents on the 
Messenger Clustering Worksheet. 


+ Under Item 12: Server Address on the Messenger System Worksheet: 


+ If you are installing the Messenger agents to each node in the cluster, use the cluster IP 
address from Item 1: Cluster Identification on the Messenger Clustering Worksheet. 


¢ If you are installing the Messenger agents to a shared disk, specify the Messenger 
resource group IP address from Item 4: Resource Group for Messenger Agents on the 
Messenger Clustering Worksheet. 


+ Under Item 13: Configure Agents for Clustering? on the Messenger System Worksheet, mark 
No. This applies to the Messenger Agents running with Novell Cluster Services, not in a 
Microsoft cluster. 


+ Under Item 14: Admin Configuration on the Messenger System Worksheet: 


+ If you are installing the Messenger snap-in to ConsoleOne to an administrator 
workstation, use the location where ConsoleOne is already installed (typically 
c:\novell\consoleone\version_number). 


¢ If you are installing the Messenger snap-in to ConsoleOne to a shared disk, use 
drive:\directory, where drive is the shared disk from Item 6: Resource for Messenger 
Administration on the Messenger Clustering Worksheet and directory is typically 
c:\novell\consoleone\version_number. 


Continue with “Setting Up Your Messenger System in a Cluster” on page 194. 
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Setting Up Your Messenger System in a Cluster 


You should have already reviewed “Planning Your Messenger System in a Cluster” on page 191 
and filled out the “Messenger Clustering Worksheet” on page 196 and the “Novell Messenger 
System Worksheet” in the Messenger 1.0 Installation Guide. Follow the instructions for the 
installation location you have chosen: 


+ “Installing the Messenger Agents to Each Node in the Cluster” on page 194 
+ “Installing the Messenger Agents to a Shared Disk” on page 194 


Installing the Messenger Agents to Each Node in the Cluster 


1 Follow the steps provided in “Starting the Messenger Installation Program” and “Creating 
Your Messenger System” in “Installing a Novell Messenger System” in the Messenger 1.0 
Installation Guide for each node in the cluster. 


2 After you have installed the software to each node in the cluster, if you selected Yes for 
Consolidate Startup Files? (under Messenger Clustering Worksheet item 3), copy the 
Messenger agent startup files to the planned location on the shared disk, then delete them from 
the c:\novell\nm\ma and c:\novell\nm\aa directories on each node to avoid future confusion. 


3 Make each node in the cluster active to make sure that the Messenger agents start successfully 
on each node. 


4 Continue setting up your Messenger system following the instructions in “What's Next” in 
“Installing a Novell Messenger System” in the Messenger 1.0 Installation Guide 


Installing the Messenger Agents to a Shared Disk 


Complete the following tasks to set up your Messenger system on a shared disk: 
+ “Setting Up the Messenger Resource Group” on page 194 
+ “Running the Messenger Installation Program” on page 194 


+ “Testing the Clustered Messenger Agents” on page 195 


Setting Up the Messenger Resource Group 


1 Create the Messenger resource group and agent services resources (Messenger Clustering 
Worksheet item 4), as planned in “Planning the Messenger Agents on Each Node in the 
Cluster” on page 192. 


2 To ensure successful short name resolution, add entries for the Messenger network name to 
support your preferred methods of short name resolution, as described in “Configuring Short 
Name Resolution” on page 150. 


3 Continue with “Running the Messenger Installation Program” on page 194. 


Running the Messenger Installation Program 


1 Ifnecessary, map a drive to the shared disk for Messenger administration (Messenger 
Clustering worksheet item 6) where you will install the Messenger snap-ins to ConsoleOne. 


2 Map a drive to the shared disk of the Messenger resource group (Messenger Clustering 
Worksheet item 4) where you will install the Messenger agent software. 
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3 Map a drive to c:\ on the first node in the cluster (Messenger Clustering Worksheet item 2) 
where you will set up the Messenger agents as a Windows services. 


4 Start the Messenger Installation program, following the steps provided in “Setting Up Your 
Novell Messenger System” in “Installing a Novell Messenger System” in the Messenger 1.0 
Installation Guide. 


5 Install the Windows Messenger agents, keeping in mind the following cluster-specific details: 


+ Use the Novell Messenger System Worksheet that you filled out during “Planning the 
Messenger Agent Installation” on page 114 to fill in the fields during the Messenger 
installation process. 


+ When you specify the Messenger installation directory, be sure to browse to the location 
through the drive mapped in Step 2 above. 


+ When you specify the ConsoleOne directory, be sure to browse to the location through 
the drive mapped in Step | above. 


+ On the Setup Complete page, do not select Launch Agents Now. 
6 Repeat Step 4 and Step 5, mapping a drive to each node in the cluster. 


Initially, you need to repeat the installation process for each node so that the Messenger agents 
are set up as Windows services on each node. For updates, you need to install only once to the 
shared disk. 


7 Continue with “Testing the Clustered Messenger Agents” on page 195. 


Testing the Clustered Messenger Agents 


After you have set up the Messenger agents on a shared disk in your Microsoft cluster, you can test 
them by manually bringing the Messenger resource group online and taking it offline again. 


Continue setting up your Messenger system following the instructions in “What's Next” in 
“Installing a Novell Messenger System” in the Messenger 1.0 Installation Guide 
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Messenger Clustering Worksheet 


Item 


1) Cluster Identification: 


Cluster name: 
Cluster IP address: 


2) Nodes in Cluster: 


3) Installation Location for Messenger Agents: 


+ Each node in the cluster 
Consolidate startup files? 


+ Shared disk 


4) Resource Group for Messenger Agents 


Network name: 

IP address: 

Physical disk: 

File share: 

Messaging Agent service: 
Archive Agent service: 
Possible owners: 


5) Installation Location for Messenger 
Administration: 


+ Administrator workstation(s) 


+ Shared disk 


6) Resource for Messenger Administration: 


Network name: 

IP address: 

Physical disk: 

File share: 

Possible owners: 

7) IP Address Resolution Methods: 
+ eDirectory 

+ hosts file 


+ DNS 
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Explanation 


Record the name and IP address of your Microsoft cluster. 


For more information, see “Setting Up Your Microsoft Cluster” on page 134. 


List the servers that are included in your Microsoft cluster. 


For more information, see “Setting Up Your Microsoft Cluster” on page 134. 


Mark the location where you will install the Messenger agent software. 


For more information, see “Deciding Where to Install the Messenger Agent 
Software” on page 192. 


If you plan to install the Messenger agent software to a shared disk, provide 
the information about the shared disk you want to use. 


For more information, see “Planning the Messenger Agents on a Shared 
Disk” on page 193. 


Mark the location where you want to install the Messenger snap-in to 
ConsoleOne. 


For more information, see “Planning Messenger Administration” on 
page 191. 


If you want to install the Messenger snap-in to ConsoleOne to a shared disk, 
provide the required information about the shared disk you want to use. 


For more information, see “Planning Shared Administrative Resources” on 
page 137. 


Mark the short name address resolution methods you want to implement to 
ensure that the UNC paths stored in ConsoleOne with network names can 
be successfully resolved into physical network addresses. 


For more information, see “Ensuring Successful Name Resolution for 
GroupWise Resource Groups” on page 137. 


Non-GroupWise Clients 


If your users already have a common POP or IMAP e-mail client that comes with Linux or 
Windows, they can continue to use it to access their GroupWise® mailboxes. Users of non- 
Group Wise e-mail clients retain the feature sets of their familiar e-mail clients, but many 

Group Wise features are not available to such users because they are not offered in POP and IMAP 
e-mail clients. 


If your users have a mobile device (Palm* OS or Pocket PC) and want to synchronize it with 
Group Wise, they can accomplish this by using GroupWise PDA Connect 1.0. In addition, there 
are several third-party tools available from third-party partners. 


+ Chapter 22, “Outlook Express,” on page 199 
¢ Chapter 23, “Microsoft Outlook,” on page 201 
+ Chapter 24, “Mobile Devices,” on page 203 
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Outlook Express 


The Group Wise Internet Agent is required in order for users to access their mailboxes using non- 
Group Wise clients. If you have not already installed the Internet Agent, follow the instructions in 
the GroupWise 6.5 Installation Guide, available on the GroupWise 6.5 Documentation page (http:/ 
/www.novell.com/documentation/gw65/index.html). 


In order for users to access their GroupWise® mailboxes from a third-party e-mail client, they must 
configure their e-mail clients to access their GroupWise accounts. For example, Outlook Express 
users would follow steps similar to the following: 


NOTE: Steps might vary depending on the versions of Windows* and Outlook* Express installed on the 
workstation. 


1 In Outlook Express, click Tools > Accounts > Add > Mail. 


2 Follow the prompts and provide personal information until you are prompted for the e-mail 
server information. 


Internet Connection Wizard xj 


E-mail Server Names 


My incoming mail serverisa |POP3 v| server. 


Incoming mail (POP3, IMAP or HTTP) server: 


An SMTP server is the server that is used for your outgoing e-mail. 


Outgoing mail (SMTP) server: 


cres | 


3 Select POP3 or IMAP as your incoming mail server type. 


4 In the Incoming and Outgoing Mail fields, specify the IP address or hostname of your mail 
server, then click Next. 


If you do not know your mail server information, contact your GroupWise administrator. It is 
the IP address or hostname of the server where the Internet Agent for your Group Wise system 
is running. 


5 Continue following the prompts and providing personal information until the new account has 
been set up in Outlook Express. 


6 Click Tools > Accounts. 


7 Select the new account you just created, then click Properties > Servers. 
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2 gwmail.net Properties 2) x) 


General Servers | Connection | Security | Advanced | 


Server Information 
My incoming mail server is a server. 
Incoming mail(POP3}: [awmailnet 
Dutgoing mail (SMTP): [owman 
Incoming Mail Server 
Account name: ltanaka 
Password: ee o 


V Remember password 


T Log on using Secure Password Authentication 


Outgoing Mail Server 


IV My server requires authentication Settings 


8 Select My Server Requires Authentication, then click OK. 


The default setting for server authentication is Use Same Settings as My Incoming Mail 
Server, so you do not need to change any settings. 


9 To access your GroupWise mailbox in Outlook Express, click Tools > Send and Receive. 
10 Click the IP address or hostname of your mail server. 


11 Provide your username and password, then click OK. 


200 GroupWise 6.5 Interoperability Guide 


Microsoft Outlook 


The GroupWise Internet Agent is required in order for users to access their mailboxes using non- 
Group Wise clients. If you have not already installed the Internet Agent, follow the instructions in 
the GroupWise 6.5 Installation Guide, available on the GroupWise 6.5 Documentation page (http:/ 
/www.novell.com/documentation/gw65/index.html). 


If your users have been using the Microsoft* Outlook e-mail client that comes with Microsoft 
Office, they can continue to use POP or IMAP in it to access their GroupWise® mailboxes. 


In order for users to access their GroupWise mailboxes from Outlook, they must configure 
Windows to access their GroupWise accounts. For example, Outlook users would follow steps 
similar to the following. 


NOTE: Steps might vary depending on the versions of Windows and Outlook installed on the workstation. 
1 In the Windows Control Panel, double-click Mail. 
2 Click Show Profiles > Add to add a new profile for your Group Wise account. 
3 Type a name for the new profile, the click OK. 
4 Select Add a New E-Mail Account, then click Next. 


E-mail Accounts E 2) x) 
Server Type gA 
You can choose the type of server your new e-mail acount will work with. > 


C Microsoft Exchange Server 
Connect to an Exchange server to read e-mail, access public folders, and 
share documents. 

C pops 
Connect to a POP3 e-mail server to download 
your e-mail, 

C IMAP 
Connect to an IMAP e-mail server to download e-mail and synchronize 
mailbox folders. 

C HTTP 
Connect to an HTTP e-mail server such as Hotmail to download e-mail and 
synchronize mailbox folders. 

C Additional Server Types 
Connect to another workgroup or 3rd-party mail server. 


Next Cancel | 


5 Select POP3 or IMAP as your incoming mail server type, then click Next. 
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zizi 
Internet E-mail Settings (POP3) sA 
>ii 


Each of these settings are required to get your e-mail account working. 


User Information Server Information 


Your Name: | Incoming mail server (POP3): 
E-mail Address; | Outgoing mail server (SMTP): 


Logon Information Test Settings 

User Name: LOOO yO After filling out the information on this screen, we 
recommend you test your account by clicking the button 

Password: | below, (Requires network connection) 


IZ Remember password Test Account Settings s 


T Log on using Secure Password 
Authentication (SPA) 


Next Cancel | 


6 Provide the e-mail account settings for the type of server you selected. 


If you do not know your mail server information, contact your GroupWise administrator. It is 
the IP address or hostname of the server where the Internet Agent for your Group Wise system 
is running. 


7 Click Test Account Settings to make sure that you have provided the information correctly. 


8 Click Next, then click Finish. 
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Mobile Devices 


If you own a mobile device (Palm OS or Pocket PC), you can synchronize it with GroupWise® 
using GroupWise PDA Connect 1.0. GroupWise PDA Connect is designed to work on a Windows 
computer to synchronize data between GroupWise and a PDA device. It is comprised of a 
synchronization engine and translators, which are used for seamless integration with the data 
source’s features and data. 


+ “Prerequisites for PDA Connect 1.0” on page 203 
+ “Downloading Required Software” on page 203 
+ “Third-Party Partners” on page 204 


Prerequisites for PDA Connect 1.0 


Before installing GroupWise PDA Connect 1.0: 


+ Ensure that Microsoft* ActiveSync* is installed for the Pocket PC or Palm HotSync* 
Manager is installed for the Palm OS. 


¢ Ensure that GroupWise 6.5.3 is installed. 


¢ Ensure that you are not synchronizing anything in Outlook (such as e-mail, calendar, tasks, or 
notes) in either ActiveSync or PocketMirror*. 


Downloading Required Software 


Downloading GroupWise 6.5.3 


You can download the required GroupWise Support Pack from the GroupWise 6.5 Product 
Updates page (http://support.novell.com/filefinder/16963/index.html). 


The download is available as a self-extracting (.exe) file. 
1 In the list of Support Packs, click GroupWise 6.5 Client SP3. 


2 Click the filename (gw65sp3c.exe), then follow the instructions to download the file into a 
temporary directory. 


3 Extract the .exe file into a directory at the root of your local drive or to a network server drive 
that can handle long pathnames. 


The compressed file contains directory paths that could exceed DOS limits. 
4 Click Start > Run > Browse. 
5 Select the setup.exe file on the local or network drive. 


6 Click OK to run the GroupWise Installation program. 
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7 Follow the on-screen instructions provided in the GroupWise installation to update the client 
software. 


Downloading GroupWise PDA Connect 1.0 


Group Wise PDA Connect 1.0 is available for download at the Novell Product Downloads Web site 
(http://download.novell.com/pages/PublicSearch.jsp). 


The download is an executable (.exe) file. 
1 Select GroupWise as the product, then click Submit Search. 
Click GroupWise PDA Connect 1.0. 
Click the filename (setup.exe), then follow the instructions to download the file. 
Click Start > Run > Browse. 
Select the setup.exe file on the local or network drive. 


Click OK to run the GroupWise PDA Connect Installation program. 


vu Oo GF A WO N 


Follow the on-screen instructions provided in the GroupWise PDA Connect Installation to 
install the software. 


Third-Party Partners 


Novell partners with several third-party companies for synchronization of mobile devices. A 
complete list of the third-party partners can be found on the GroupWise Partner Product page 
(http://www.novell.com/partnerguide/p 10003 1.html). 
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Unsupported Web Servers 


The GroupWise WebAccess Installation program installs the WebAccess and WebPublisher 
Applications to the Web servers listed in “WebAccess System Requirements” in “Installing 
GroupWise WebAccess” in the GroupWise 6.5 Installation Guide. These are the Web servers for 
which Novell Support provides support. 


You can manually set up WebAccess to work with other Web servers and servlet engines by 
completing the following tasks: 


+ Chapter 25, “Installing WebAccess to Unsupported Web Servers,” on page 207 


+ Chapter 26, “Configuring WebAccess to Use a Java Servlet Engine Other Than the Novell 
Servlet Gateway or Tomcat Servlet Engine,” on page 209 
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Installing WebAccess to Unsupported Web 
Servers 


If necessary, you can run the WebAccess and WebPublisher Applications on an unsupported Web 
server as long as the Web server supports a Java servlet engine that is JSDK 2.0 and JDK* 1.1.6 
compatible. However, the Installation program does not install the applications to other Web 
servers, which means you must manually install and configure them. When you run the Installation 
program, deselect the options to install the WebAccess Application and WebPublisher 
Application, install the WebAccess Agent, then complete the following steps to install the 
applications: 


1 Unzip webaccess.zip to the root of the network server volume where the Web server resides. 


The webaccess.zip file and the ZIP files referred to in the next three steps are in the 
\internet\webacces\other directory of each GroupWise 6.5 Support Pack. 


2 Unzip webaccessdocs.zip to the Web server’s document root directory. 
3 Unzip webaccessservlets.zip to the servlet root directory. 


4 Unzip webaccessjars.zip to a library or jar file directory on the network server (for example, 
you might want to create a \novell\lib directory), then add the jar files (Idapfilt.jar, Idapjdk jar, 
njgwap.jar, njweb.jar, spellservlet.jar, xalan.jar, and xerces.jar) to the class path. 


5 Modify your Java engine’s servlet properties file to include the settings provided in the sample 
WebAccess servlets.properties file. 


The WebAccess servlet.properties file is located in the \internet\webacces\other directory of 
each Group Wise 6.5 Support Pack. 


6 Modify the Templates.path setting in the webacc.cfg and webpub.cfg files, located in the 
\novell\webaccess and \novell\webpublisher directories, to replace java/servlets with the path 
to the servlet root directory. 


7 Ifyou created the \novell directory structure in the location specified in Step 4 (the root of the 
volume where the Web server resides), the paths for the following settings in the webacc.cfg 
and webpub.cfg should already be correct. If not, you need to modify the paths to make them 
correct from the perspective of the Web server. 

File.Upload.path 

Log.path 

Security. Timeout.path 

Provider.G WAP.Config.file 
Provider.LDAP.Config. file (webacc.cfg only) 


8 Copy the index.html file to the Web server's document root directory. 


You can replace your Web server's current default home page with this file, or you can rename 
the file and link to it from your current default home page. 


9 Copy the commer.cfg file, located in the WebAccess gateway home directory 
(domain\wpgate\webac65a), to the \novell\webaccess directory and the \novell\webpublisher 
directory. 
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Configuring WebAccess to Use a Java Servlet 
Engine Other Than the Novell Servlet Gateway 
or Tomcat Serviet Engine 


If you use a Java servlet engine other than the Novell Servlet Gateway or the Tomcat servlet 
engine, the servlet engine needs to be JSDK 2.0 and JDK 1.1.6 compatible. 


After you've installed WebAccess, complete the following steps to configure WebAccess to work 
with the Java servlet engine: 


1 Modify the Java servlet engine’s servlet properties file to include the settings provided in the 
sample WebAccess servlets.properties file. 


The sample servlets.properties file is located in the \internet\webacces\other directory of each 
Group Wise 6.5 Support Pack. 


2 In the webacc.cfg and webpub.cfg files, modify the Templates.path setting to replace java/ 
servlets with the path to the servlet root directory. 


The files are located in the novell\webaccess and novell\webpublisher directories on the root 
of the server. 


3 Add the WebAccess jar files (Idapfilt jar, Idapjdk.jar, njgwap.jar, njweb.jar, spellservlet.jar, 
xalan.jar, and xerces.jar) to the class path. 


On a NetWare server, the jar files are located in the java\lib directory. On a Windows server, 
the files are located in the novell\java\lib directory. 
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Documentation Updates 


This section lists updates to the GroupWise 6.5 Interoperability Guide that have been made since 
the initial release of GroupWise® 6.5. The information will help you to keep current on 
documentation updates and, in some cases, software updates (such as a Support Pack release). 


The information is grouped according to the date when the GroupWise 6.5 Interoperability Guide 
was republished. Within each dated section, the updates are listed by the names of the main table 
of contents sections. 


The GroupWise 6.5 Interoperability Guide has been updated on the following dates: 


+ 


+ 


+ 


+ 


+ 


+ 


“October 31, 2005” on page 211 

“September 19 2005 (GroupWise 6.5 SP5)” on page 211 
“January 31, 2005” on page 212 

“November 30, 2004 (GroupWise 6.5 SP3)” on page 212 
“September 30, 2004” on page 212 

“September 30, 2003” on page 213 


October 31, 2005 


Location Change 


Novell Cluster Services 


“Deciding Whether to Run Strongly recommended running the agents in protected memory, with 
the Agents in Protected each agent in a separate memory space. 
Memory” on page 30 


“Deciding Whether to Run Strongly recommended running the Internet Agent as well as its MTA 
the Internet Agent and Its in protected memory, with each agent in a separate memory space. 
MTA in Protected Memory” 

on page 66 


September 19 2005 (GroupWise 6.5 SP5) 


Location Change 


Identity Manager 
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Location Change 


Chapter 11, “Identity Updated the product name from DirXML® to Novell® Identity Manager. 
Manager Warnings in 
ConsoleOne,” on page 123 


Non-GroupWise Clients 


Chapter 22, “Outlook Indicated that mail server information must be obtained from your 
Express,” on page 199 GroupWise administrator. 

Chapter 23, “Microsoft Updated the instructions for accessing your GroupWise mailbox from 
Outlook,” on page 201 Microsoft Outlook. Indicated that mail server information must be 


obtained from your GroupWise administrator. 
January 31, 2005 


Location Change 
Mobile Devices 


Chapter 24, “Mobile Added a section for mobile devices. 
Devices,” on page 203 


November 30, 2004 (GroupWise 6.5 SP3) 


Location Change 
Unsupported Web Servers 
“Installing WebAccess to Moved information from the Readme to the Interoperability Guide. 


Unsupported Web Servers” 
on page 207 and 
“Configuring WebAccess to 
Use a Java Servlet Engine 
Other Than the Novell 
Servlet Gateway or Tomcat 
Servlet Engine” on page 209 


September 30, 2004 


Location Change 
Novell Cluster Services 


“Deciding Whether to Run Corrected the recommendations for placing the Internet Agent into 
the Internet Agent and Its protected memory. 

MTA in Protected Memory” 

on page 66 and “Internet 

Agent Clustering 

Worksheet” on page 78 
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Location Change 


“Planning WebAccess ina Clarified that NetWare® 6.5 provides Apache and Tomcat rather than 
Cluster” on page 83 and the Netscape Enterprise Web Server for NetWare and that Apache and 


“Setting Up WebAccess ina Tomcat are not currently supported in a cluster. 
Cluster” on page 88 


“Deciding Whether to Run Corrected the recommendations for placing the WebAccess Agent into 
the WebAccess Agent and protected memory. 

Its MTA in Protected 

Memory” on page 86 and 

“WebAccess Clustering 

Worksheet” on page 99 


Non-GroupWise Clients 


“Non-GroupWise Clients” on Added instructions for connecting to a GroupWise system from a non- 
page 197 GroupWise client, such as Outlook*. 


September 30, 2003 


Location Change 
Novell Cluster Services 


“Forcing Use of the Internet Corrected Step 1 with the appropriate ConsoleOne property page. 
Agent Secondary IP 

Address” on page 75 and 

“Forcing Use of the Internet 

Agent Resource Group IP 

Address” on page 167 
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